Combobox / autocomplete

[dandv]

Is your feature request related to a problem? Please describe.
I'm looking for incremental search for tags input.

Describe the solution you'd like
For inspiration, autocomplete in Evergreen and Fluent UI.

Describe alternatives you've considered
https://shoelace.style/components/select?id=help-text seems to focus on the option that starts with the typed character, but the search appears to stop there.

[claytongulick]

FWIW, I've done a fair amount of work on a pure web-components implementation here: https://github.com/claytongulick/chip-input it might be a good starting point / base for implementation?

[jaredcwhite]

@claytongulick This looks pretty cool! I'll try it out =)

[jaredcwhite]

Argh, I need sl-tag-autocomplete and I need it now! haha. Maybe I should try to cobble something together with a text field, tags, and dropdown menu…

[jaredcwhite]

It has begun! https://codepen.io/jaredcwhite/pen/LYbmwgz

Haven't gotten to autocomplete/dropdown yet, but the tag input works pretty well. =)

(type in anything and hit enter. clearing works too. el.tags works for tags-input at any time.)

@claviska Having fun with Shoemaker so far!

[claytongulick]

@jaredcwhite great start!

There are a ton of little details you'll have to think about, async autocomplete so you can call out to an API, formatting in autocomplete, positioning the dropdown, styling the widgets/pills, carrying data - having a display value vs linked object value, consumable events, etc...

Feel free to browse that chip-input code to see some of what I'm talking about, lift as much from it as you can :D

[sidharthramesh]

Any updates on this @jaredcwhite? I would really like to have an autocomplete in my project. right now, I'm doing some hackery with the <sl-input> and <sl-menu>

[jaredcwhite]

@sidharthramesh Well I'm not sure if my hackery is any better than your hackery, but here's what I've got so far!

https://github.com/whitefusionhq/sl-tags-input

I went ahead and published it because I need to use it in a project. Likely needs some more detailed API design and accessibility fixes, but it's working now for my needs. I can type, pull related results in from an external data source, and pick one, or type in one manually and hit enter. Add/delete tags. etc.

[sidharthramesh]

@sidharthramesh Well I'm not sure if my hackery is any better than your hackery, but here's what I've got so far!

https://github.com/whitefusionhq/sl-tags-input

I went ahead and published it because I need to use it in a project. Likely needs some more detailed API design and accessibility fixes, but it's working now for my needs. I can type, pull related results in from an external data source, and pick one, or type in one manually and hit enter. Add/delete tags. etc.

Very cool! I'll take a look

[sidharthramesh]

@jaredcwhite did you have this issue #382 (down arrow not working properly) while using a drop-down element inside lit-element?

[jaredcwhite]

You know, actually I did. That's why I ended up making SLMenu a slotted element in the Light DOM. If the bug gets fixed I might be able to simplify and move it into the Shadow DOM template.

[sidharthramesh]

Any idea why the behaviour is different when using the same markup inside lit-html?

This is unsettling because I'm using lit-element everywhere to wrap shoelace components into more general building blocks for my use case.

Is it something to do with the shadow dom?

[claviska]

@jaredcwhite @sidharthramesh this was fixed in 20eff47 and will be available in beta.35.

[sidharthramesh]

I can create a nice search bar, if the dropdown element had some additional props. I have made these changes here #385

[claviska]

I’m renaming this to align with the W3’s definition: https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/examples/combobox/combobox-autocomplete-list.html

For accessibility reasons, I think the scope should be more or less limited to what’s described here.

[hanc2006]

@claviska,
I prepared a PR for the sl-autocomplete component (code and doc), but I need to delete and create again the PR for the sl-datepicker component #474 and the PR for the i18n localization support #479. When I created the first fork I didn't think about creating new branches for each PR. Now I can't align the code with your upstream 😢

[yuki24]

I have made this component for my own needs, in case anyone is interested:

Screen.Recording.2022-07-29.at.12.00.09.AM.mov

I can send a PR as a starter and discuss the API if there is enough demand.

[nileshtrivedi]

How is Shoelace website's own search feature implemented?

[patricknelson]

That would be perfect.

Right now it looks like it's just a simple search.js script (canonical link if it ever changes). But the simplicity of it is great.

Edit: Looks like he commented on it below, too. 😬

[claviska]

It’s a makeshift script that doesn’t work properly with screen readers. I fixed that problem in Doxicity, but I haven’t had a chance to rebuild the whole website yet.

It’s even more of a challenge to get it right when composing a combobox with custom elements. Not impossible, but not exactly simple.

[atomkirk]

Just thought I'd pipe in and call for some overall vision planning here. In my experience, I've run into many variations of dropdowns/selects and they all share common elements, but are necessary for different scenarios. Pretty much all of these components are needed on a modern app so IMO a standard component library should support all of these use cases.

Here's the notes I've made over the years:

Selection Dropdown

Select one item from a short list.
Necessary for whenever one and only selection should be made from a short list of choices. The other alternative is radio buttons, which make more sense when each option is a long text. This is so common its built into the browser. It's just ugly.

Action Dropdown

A short list of actions to take.
This is nice at the top of a table for taking action on selected rows for example. It kind of groups similar items into one hidden UI item that doesn't clutter the UI until you need it/click on it.

Autosuggest

People call this autosuggest, but it's really a select dropdown where you can search the list of options.
This is great when the item is so long it'd be very tedious to scroll through it looking for the item to select.

Long Action Dropdown

Less common, but sometimes you have a really long list of actions you can take and the ability to search them is nice. Not planning to support this use case would be understandable, but I have seen it before…

Multi-Select

A dropdown that lets you select multiple items. The selections are shown as pills or chips or something. You can click them to deseletc.

Long Multi-Select

Same as Multi-Select but lets you search to select. Also similar to autosuggest, just allows selecting multiple things.

Another potential use case that I've never seen is selecting multiple actions and then selecting multiple actions from a long list with search. The difference between an action and selection categories is that the anchor or trigger component doesn't change where with select the anchor shows the current selection(s).

So the variables for the dropdowns I've needed over the years are:

• Selection or action
• Short or long (requiring search)
• Single or multiple selections

Things these all have in common are:

• There's some kind of popover containing the options.
• I think every one of these should let you provide your own component for the options rows. (e.g. showing avatars on a dropdown to select an assigned user.) That component should allow you to pass it the currently types string so the component can highlight matching content within the row.

I was king of thinking it might be a good idea for Shoelace to come up with a long term plan for how these things could fit into the offering. Whether thats as a single component or a few components, I think it'd be helpful to think ahead so that interfaces and code can be written with the long term plan in mind. I'm very willing to contribute and start to implement once you/we have that plan. You could make it all one component with options, you could make 2-3 components that use shared components common between them, etc. But I do feel strongly that all of these components are needed in most modern apps of even moderate complexity. Thanks for reading :)

[tpluscode]

I experimented a little on the sample provided by @nileshtrivedi

Here's an extract from my project's source code:

https://studio.webcomponents.dev/edit/3WC1qIWWF6aSTPA6ASKK/src/index.js?p=website

I think I got it fairly usable with two simple tweaks:

1. Preventing the default key event on space which would open the menu
2. Add a loading flag and automatically open/close the menu when it is toggled

[yuki24]

I have sent #1002 as a starter. While this is still missing a lot of things, you should all be able to give it a try on https://shoelace-git-fork-yuki24-combobox-component-shoelace.vercel.app/components/autocomplete. Would love any feedback on that. Thank you!

[chrisjameslennon]

I have sent #1002 as a starter. While this is still missing a lot of things, you should all be able to give it a try on https://shoelace-git-fork-yuki24-combobox-component-shoelace.vercel.app/components/autocomplete. Would love any feedback on that. Thank you!

Looks good. I think it just needs to auto drop down on click in.

[chrisjameslennon]

I guess the difference between an auto-complete input and a select control, apart from the visual aspects, is that an auto-complete will allow text that is not one of the suggested options. Not sure this needs to be a separate element? Perhaps could be a property of sl-input? However it is implemented this would be a welcome addition, as there is no current way to give the user suggested input in Shoelace it seems?

[claviska]

Accessibility remains the biggest hurdle, as we want to allow options to be defined declaratively but we can't link ids across shadow boundaries. It's not impossible, but it's definitely not trivial with the tools we currently have available.

[bcbweb]

Any progress on this? I like the idea of just augmenting the sl-input component to support this, e.g. via an autocomplete-data property

[mariohamann]

Messaged @KonnorRogers on Mastodon on this but wanted to express need for this component in this discussion here, too – and would like to ask if there's a way to support in any way on this or if there's a way to get a feelin gfor the API you're aiming for, so we could built a component which doesn't differ too much from your later implementation. :)

[trusktr]

I'm researching element libs for a new project and combobox/autocomplete is one of the main things I need to filter through lots of items.

Many of the demos/concepts above are broken (Y'all! Please don't forget to add version numbers to your dependencies (f.e. //unpkg.com/[email protected]/bar) so demos don't break!).

---

It would be great to have this feature even without accessibility, as there are many scenarios that don't require it. Right now the bigger portion of people are blocked here because accessibility is a hurdle for satisfying a smaller portion of people.

Isn't something more accessible than nothing? Perhaps it doesn't have to be an all-at-once solution:

Proposal:

What if clearly highlighted labels (f.e. non-accessible) are shown in the docs for certain elements as long as they lack accessibility. That way something exists that satisfies many use cases, and when accessibility finally gets ironed out for a given element the label gets removed? The label could clearly inform people who need accessibility which elements to avoid, while a bigger portion of people can take advantage of certain features as needed.

---

What is the most difficult hurdle with the accessibility?

[mparpaillon]

Accessibility doesn't need to offer 100% of the functionality. A fallback to a regular select (which accept the selection from keyboard) is enough to make it accessible to all.

[KonnorRogers]

@mparpaillon A <select> is functionally different from an autocomplete for many reasons. Accessibility should offer 100% of the functionality. You shouldn't be leaving users behind just because they don't navigate the web the same as everyone else.

@trusktr While I appreciate the idea, the problem is that accessibility largely guides the creation of our components. We don't want to leave people behind, and users trust us to create components that will work well for all their users. Especially because some places are contractually obligated to meet accessibility requirements. The most difficult hurdle to accessibility is mostly around cross-root aria. I think we have an idea right now around cloning options users pass in the light-dom and cloning them into the shadow-dom. It's kind of unexpected behavior, but until something like this lands:

https://github.com/leobalter/cross-root-aria-delegation/blob/main/explainer.md#generic-proposal

Where we essentially get the ability to "delegate" aria attributes across roots, we're kind of stuck needing every element to live within the same "document" or rootNode.

[Offbeatmammal]

is this the $600k level stretch goal? https://www.kickstarter.com/projects/fontawesome/web-awesome
if so .... gotta get more people to sign up quick ;)

[rpsirois]

Haha ikr I was thinking the same thing. I signed up!

[tamara-nexus]

Hello, I have been checking the different issues / discussions on select and auto-complete. This is good to have. I wondering if this is the place where in list filtering (in select/multi-select) should be discussed too.

Basically filtering items already in the list like this example:
https://primereact.org/dropdown/#filter

It is nice that the Select component in Shoelace supports single and multi-select and has an option for clearing selection etc...
Would it be possible to have an inner filter for its items?

Thanks!

[timsofteng]

Hey guys. Any plans to include this feature?

[KonnorRogers]

@tamara-nexus This would be a combo of a <sl-dropdown> and <sl-combobox> (whenever it lands)

So you'd roughly end up with something like:

<sl-dropdown>
   <button slot="trigger" aria-haspopup="dialog" aria-expanded="false" aria-controls="combobox"></button>
   
   <sl-combobox id="combobox"></sl-combobox>
</sl-dropdown>

^ More like pseudo-code, but more so providing the structure (not sure if <sl-popup> or <sl-dropdown> is better here, would have to play with it). This may live as a variant on combobox, im not sure yet, as there's just enough to manually hook up with aria attributes and event listeners to make it a pain to build yourself.

Most components I've seen of this just get completely swallowed by screen readers.

The example you linked, and the ShadCN combobox both have this problem. They dont have the proper aria-* attributes and end up just reading nothing.

[tamara-nexus]

Thanks! Sorry for the late reply. I was out of office for the past month. Thanks for the clarification. It is really nice that your team is paying close attention to accessibility and screen reader support. From what I am seeing in EU, the regulatory demands are increasing for that and it is becoming less optional to support accessibility. Well, we need to build more inclusive UIs anyway :)

[hmarcelino]

Hi guys any news regarding the autocomplete ?