Re: [w3ctag/design-reviews] Incubation: Filterable select (Issue #1264)

dandclark left a comment (w3ctag/design-reviews#1264)

Thanks for sending this to the TAG. We're happy to see this being worked on, as a continuation of prior efforts to make native `<select>` more customizable and useful.
 
On the [3 approaches](https://open-ui.org/components/filterable-select.explainer/#proposed-approach) being considered:
 
For Option B, we agree that webcompat and lack of progressive enhancement is a major issue with this approach and probably sufficient to block it. It'd be interesting to compare with `<button>`-inside-`<select>`, which historically also didn't work but is now allowed for customizable select in supporting browsers. Allowing that was a similar breaking change that seems to have been proven feasible. Do you know how current usage of `<input>`-inside-`<select>` parsing rules compares to historical dependence on the `<button>`-inside-`<select>` parsing rules at the time that change was made? If the usage numbers are comparable or lower for `<input>`-inside-`<select>` then this may still be feasible in terms of web compat. Progressive enhancement remains a problem though unless all browser implementations can align in shipping this change.
 
Assuming B remains a non-starter for those reasons, we'd support an approach like the one proposed [here](https://github.com/whatwg/html/issues/12050#issuecomment-5441690356), where `<select>` gets a `filterable` attribute as described in Option C that would make the common case easy, and something like Option A is pursued later if there is still demand for flexibility beyond what C can achieve. The internal `<input>` would need to be styleable through a pseudo element. It's unfortunate though if a lot of properties specific to filtering would need to be added to `HTMLSelectElement` to support this, especially if they'd be redundant with properties eventually added to HTMLInputElement for Approach A or for [Combobox](https://open-ui.org/components/combobox.explainer/). From the discussion in https://github.com/openui/open-ui/issues/1491 it looks like only a few properties would be needed, but if that list grows this approach should probably be reconsidered in favor of Option A.

We're happy to see that you're engaging with the developer community about these approaches, and if dev feedback strongly pushes towards one of these options, we'd support following that feedback.
 
Other miscellaneous thoughts:
- The [proposed UA stylesheet](https://open-ui.org/components/filterable-select.explainer/#css-reactive-rendering-filtered) has `option:filtered` given `display: none !important`, but the `!important` seems overly constraining. What if a developer wants to have filtered options grayed-out or crossed-off instead of disappeared (although devs would need to be careful to exlude such options from the a11y tree and from focus order)? It'd be good to ensure that animations between filtered and non-filtered states also work well.
- The explainer mentions the `search` attribute a couple times in passing but it isn't really defined in this document. We assume this is referring to https://open-ui.org/components/combobox.explainer/#the-search-attribute -- if so it'd be good to link that directly, or inline an explanation into this explainer.
- We assume `<select multiple>` is in scope here since the GitHub label picker example is a multi-select. It would be good to have the explainer confirm this, and to ensure the accessibility implications with `<select multiple>` are also being considered (as was at least briefly discussed in https://github.com/w3c/aria/issues/2841).
- For option A, is "sibling" a hard requirement or can the `<input>` and `<select>` (and `<selectedcontent>`) be in different places in the DOM? It may be best not to be too strict on this requirement to allow for different DOM structures. For full composability, it could be desirable to have these be linkable across shadow DOM. Reference Target could forward the `filter` ID into a shadow root. Consider adding a corresponding reflecting IDL attribute like `input.filterElement`, which would allow the filter `<input>` to connect to a `<select>` in a parent shadow.
  - If Option A is selected, the attribute name `filter` may be worth bikeshedding. The current name sort of reverses the intended semantics: `<input filter=foo>` could be read like the thing with ID `foo` is the filter for the input, but what we want to express is the other way around where the `<input>` is the filter for the `<select>` foo. `<input filters=foo>` could work better since it reads like "this input filters the element with ID foo", but maybe the `s` could be confused for a pluralization. Maybe `filterfor`?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1264#issuecomment-5922072735
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1264/5922072735@github.com>