Filtering support for customizable select

[josepharhar]

What problem are you trying to solve?

A common use case for select-like components on the web is the ability to filter the rendered options by typing into a text field. For example, the "Labels" picker here on github has a listbox of labels with a text field above it to filter the labels.

What solutions exist today?

To build this today, you would need to build your own input and listbox components, set up the ARIA so that the text field can control the listbox, and build a lot of keyboard and focus behavior which allows the user to type into the listbox while simultaneously using the arrow keys to choose options from the listbox.

How would you solve it?

We have been discussing this use case for a while in OpenUI here: openui/open-ui#847
Some potential solutions discussed in that issue include:

1. Allow authors to put an input element inside the select element which performs filtering.
   1. Pro: minimal markup for authors
   2. Pro: authors can still fully access the input element to customize behavior
   3. Con: The parser doesn't currently allow for input elements inside the select element due to site compat issues, where sites omit the select end tag and rely on the input tag implicitly closing the select tag.
   4. Con: The input element needs to exist outside of the listbox in order to control it for a11y and keyboard purposes. However, if we just allow authors to put it in the select somewhere, it would become difficult or impossible to make the browser wrap all of the options in a container that doesn't exist in the DOM. The fact that the input could exist anywhere in the select makes this harder - I imagine that we would have to traverse the entire subtree of the select element, look for input elements and options, decide if they are positioned correctly (input before all options), then decide where to build a secret listbox that we can put all the options in which is controlled by the text input, and make the popup a dialog instead of a listbox.
   5. Con: Doesn't accommodate for complex pickers like the Labels picker on github, which also has an "Edit labels" button after the listbox.
2. Add an HTML or CSS opt-in to display a filter input automatically
   1. Pro: minimal markup for authors
   2. Con: doesn't allow authors to directly access the input element, so we would have to add a lot of APIs to the select element to let authors control it, such as an IDL to see the value typed into the input element and events which fire when the user types a character into it.
   3. Con: Doesn't accommodate for complex pickers like the Labels picker on github, which also has an "Edit labels" button after the listbox.
3. Add markup to allow authors to connect an input element to a listbox select element, which an author could put in their own picker
   1. Pro: This is a simple building block which authors can use to build their own pickers with additional interactive elements like the Labels picker on github or something that exists outside of a picker entirely.
   2. Pro: authors have full access to the select element to customize behavior
   3. Con: Additional markup required for authors to build their own picker since they have to declare an element to be the picker and use attributes to connect the pieces

I think option 3 of adding markup is the best because it is relatively simple and enables significantly more use cases.

Anything else?

There is also an OpenUI discussion about javascript APIs to modify how filtering works which would support use cases such as fetching results from a server and could also be applied to the input with datalist pattern: openui/open-ui#931 (comment)

[josepharhar]

This openui explainer also covers this use case in addition to combobox: https://open-ui.org/components/combobox.explainer/