[SELECT] Usecases & solution for filtering

[gregwhitworth]

There was agreement amongst the group that text input should be possible on the select element, so this isn't solely a capability for a <combobox>. There then was discussion around being on by default or using an attribute and this illuminated that we need to determine what occurs when the attribute is/isn't provided.

For this specific issue however I'm going to close it out as we have determined that the scope of the select does allow for search input. There was also general agreement that a combobox allows for entry of options that aren't available in the provided option set (similar to an input with datalist). That said we did not resolve if this would be the same behavior of select or not. I will open an issue to explore the attribute and specific usecases between scrolling into view and filtering and what this may look like with regards to implications on anatomy and eventing.

Originally posted by @gregwhitworth in #104 (comment)

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

It looks like a combobox has been implemented with selectmenu in the demos here: https://microsoftedge.github.io/Demos/selectmenu/
Is there additional support we should add to selectmenu for this use case?

[josepharhar]

It looks like the demo I mentioned in the last comment implements filtering by replacing the listbox popover and putting an input element in it. If replacing the listbox is good enough for this use case, then I think we can close this issue.

[LeaVerou]

Maybe this can just be part of the control UI, rather than part of the author-facing API. What if a search input (i.e. not one that allows freeform entries to be inserted) appears once the number of options increases beyond a specific number? A search field isn't particularly useful with few entries, and it just adds clutter, whereas it's almost always useful in menus with a lot of entries.

[css-meeting-bot]

The Open UI Community Group just discussed [SELECT] Usecases & solution for filtering, and agreed to the following:

• RESOLVED: The ability to filter options should continue to be discussed, but not in the context of the "v1" <selectmenu> control.

The full IRC log of that discussion

<gregwhitworth> Topic: [SELECT] Usecases & solution for filtering
<gregwhitworth> github: https://github.com//issues/115
<masonf> q?
<masonf> q+
<gregwhitworth> q+
<hdv> jarhar: this issue is about that the edge demos included a selectmenu that works like a combobox
<jh3y> q+
<hdv> masonf: we also resolved somewhere else that it's a single selectmenu only for v1, so that you can make it a combobox-y thing with some JavaScript if you want to, so could close this?
<gregwhitworth> ack masonf
<hdv> gregwhitworth: historically the group we've kind of stood by that design systems usually have a separate component for combobox
<hdv> gregwhitworth: so maybe we can rename this issue or close and revive it later, to avoid that these are conflated with other types of selectmenu… maybe need to reword it
<gregwhitworth> ack gregwhitworth
<hdv> masonf: for popover I added a label popover-v2, we could do the same for selectmeniu, so that it is not closed but just labelled
<hdv> gregwhitworth: what are some scenarios where you would want to filter a selectmenu that is not a combobox?
<hdv> lea: what if instead of of making it is part of the API it is an option in the browser UI, automatically, when the number of options grows beyond a certain number, like 20… and it doesn't show with fewer entries?
<gregwhitworth> ack jh3y
<hdv> jh3y: if you start thinking about virtualising lists it could be a whole rabbit hole
<hdv> jh3y: I guess datalist kind of covers some of this is some ways… seems this comes down to giving people choice in the right way?
<hdv> jh3y: it would also be good to have accessibility review on it
<masonf> q?
<hdv> gregwhitworth: I'm supportive of pushing this into a v2… we can evolve what is there today, today you can just style and extend it.
<masonf> q+
<hdv> jh3y: there are some ways you can implement it today, like you can put an input in the button slot
<gregwhitworth> ack masonf
<gregwhitworth> q+
<hdv> masonf: yes, we should probably label it v2, but continue talking about it now to gather ideas. What Lea said about automatic filter… to have something to make it easier to do it via CSS… what we have today is a scrolllable list… if there is a nifty way to make the combobox-y thing to do this in CSS that we could add to the UA stylesheet that would be nice
<hdv> lea: was thinking what would the syntax look like… would it even be part of CSS or part of the HTML… don't know… lot's to think about
<hdv> ack greg
<hdv> gregwhitworth: I propose we punt it to v2, like masonf's earlier proposal. We bring this back up, because filtering means usually you want to give user feedback of what's filtering but then it's no longer an input, then it's more like a combobox
<hdv> gregwhitworth: from the surveys we've seen combobox by far is what people are wishing for us to do
<hdv> gregwhitworth: if we can do select/select multiple, then go on to combobox, we will hit this issue and solve it
<tantek> +1 be part of CSS of HTML
<hdv> gregwhitworth: do people feel it makes sense to punt it to v2?
<tantek> s/of HTML/or HTML
<hdv> jh3y: I can create a bunch of demos
<masonf> Proposed resolution: The ability to filter options should continue to be discussed, but not in the context of the "v1" <selectmenu> control.
<masonf> RESOLVED: The ability to filter options should continue to be discussed, but not in the context of the "v1" <selectmenu> control.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.