The scope of the select control

[gregwhitworth]

In discussing the <select> with some people there is a desire to allow for an input to allow filtering of the available options. Some component libraries bundle this in with their select and others refer to this as a combo box. I'm going to do some research as I think it's important to ensure that the anatomy we're defining allows this extensibility if we believe it to be an expected part of the <select>.

[chaance]

Some important potential distinctions to consider while researching:

• In a native MacOS select, when the menu opens the popover is positioned directly over the top of the currently selected option, which obscures the trigger button. You likely don't want this with a combobox, as the input retains focus and the popover changes as the user continues to interact with the component (unsure if positioning should be left to spec or a consumer to customize, but the positioning will impact the spec for events in the MacOS example)
• The popover may position itself based on collisions. With a select this is a bit more straight forward as options don't typically appear/disappear while it's open. With a combobox it does, and collisions/positioning may change as a result. In both cases collisions may change if the user scrolls while the popover is open.
• Not sure how we've landed on focus locking inside an open select menu if there are nested tabbable elements. Some implementations lock, some close the menu on tab and continue to the next element after the trigger. In a combobox you can't really lock focus inside the popover because focus needs to stay in the input while the user types and interacts with the list.

[gregwhitworth]

@chancestrickland thanks but that's not necessarily the purpose of this issue. Those seem like behavior considerations and most of the ones you noted are actually style based solutions which Open UI does not try to go after. This discussion is for the semantic meaning of the <select> versus a combobox both in written form and in practice. The reason for this was born from a discussion with @mfreed7, @una and other webdevs that a common desire from the <select> and why they re-build them is to have an input that allows filtering of the available options.

So my desired outcome from this issue is to determine:

1. Whether Open UI recommends that there should be two separate controls for select and combobox, why or why not.
2. How we plan to accomplish the search need within select if we decide that they should both exist but filtering should be expected offering on a select.

[chaance]

Makes sense to me for positioning, though is focus management not more of a behavioral thing we should be concerned with? And if it is, would that make a difference as to whether or not the two are separate controls or is there room for that kind of variance in a single spec?

[gregwhitworth]

@chancestrickland Focus will be, I'm saying this specific issue isn't for investigating those. We have landed on some focus issues such as #74 and #82 and if you feel there others please feel free to file them in separate issues.

[una]

We discussed an attribute on select (i.e. filter='true') rather than separating the components into a select and combo-box. The reason around this is because the core functionality of the select with a filter is identical to select – it just has a different search mechanism (type instead of scroll) to find the correct option value.

This is also only valid in the conversation around slotted parts and breaking up select components, but I think it's a pretty common usecase and would make a pretty neat feature.

[gregwhitworth]

Alrighty, here is a quick rundown of the research I did around whether searching should/shouldn't be an addition to <select>.

Here are results for whether the component lib offered a search capability for a given name that is similar to the <select> (because not every component lib refers to their <select> as a <select> although that is the Open UI name).

Name	Ant Design	AtlastKit	Carbon	Evergreen	Lightning	FAST	Semantic UI	Fluent	WIA-ARIA
Select	✔	✔							✔
Combobox	N/A	N/A	✔	✔	✔	N/A			✔
Dropdown				N/A	N/A	N/A	✔	✔

So here's the breakdown across the component libs I looked at that had search functionality

• Select: 3/7 (42%)
• Combobox: 4/6 (66%)
• Dropdown: 2/ 5 (40%)

Given the above numbers I'm personally indifferent here on whether this should live on the <select> so this come down to whether we want an attribute to adjust the anatomy & behavior of the <select> or to have a separate control that is overall similar to that of the <select> but allows typing for search.

Another aspect to consider is the goal of each control. Once you can type into the control are you solely filtering the available options or can you also add to the options that may not be available?

All of the libs above from what I found they only filtering, similar to datalist or current functionality in Chromium, Webkit, Gecko. Also, looking at Windows and MacOS, Android native controls this is the same (I don't have iOS).

MAC

Android

Windows

One final item is the definition of a combobox:

A combo box is a commonly used graphical user interface widget (or control). Traditionally, it is a combination of a drop-down list or list box and a single-line editable textbox, allowing the user to either type a value directly or select a value from the list. The term "combo box" is sometimes used to mean "drop-down list".[1] In both Java and .NET, "combo box" is not a synonym for "drop-down list".[2][3] Definition of "drop down list" is sometimes clarified with terms such as "non-editable combo box" (or something similar) to distinguish it from "combo box".

Because we have datalist and input already in the platform I prefer to introduce a new element called combobox that has its own anatomy of an input. While that is my preference I do not feel strongly about it based on the research above but I do feel it is cleaner. Another consideration is that email clients and tag lists often allow you to insert content that isn't currently in the available options. This would then be yet another attribute to add.

So the initial options are:

1. Add an attribute to the <select> and this will produce an input to allow users to type in to select an option from the list
2. Introduce a combobox element that has an anatomy of a listbox and an input where users can type to filter the list

I didn't include dropdown in the options because the general consensus is on <select> in the industry for this control with combobox close behind.

[gregwhitworth]

I sent out a tweet to get a general idea from the webdev community: https://twitter.com/gregwhitworth/status/1272694314460573697

[jouni]

Based on one of the twitter poll comments, I agree that filtering/search is a user convenience for the select component. I would probably still make it opt-in, as it should only be needed if the number of options exceeds some limit, and would just be in the users way if there are something like less than 5 options to choose from.

That said, I would still add have a separate combo box component (note, my thinking is half-baked here).

Select is for cases when the users is only allowed to choose from a predefined set of options. Combo box is for cases when the users is also allowed to enter any arbitrary string value.

Both offer a filter/search, but in different places in the UI. In select, the filter input is inside the popup (like in GitHub branch select). In combo Box, the filter input is the main control itself.

The combo box component lends itself better to chip/token inputs, than a select.

If we try to combine the two into one control, I feel it’s going to be difficult to cover all use cases nicely.

---

Does it make a difference whether the options in the list translate easily to string values? For example, git branch name vs icon/image? I could imagine using either a select or a combo box for the branch name, but for the icon/image, select would seem more natural somehow.

[MattWilcox]

My vote is for attr on select, which is a graceful fallback when not implemented in a browser.
This is purely to filter existing options within the select though.

IF instead the idea was that the text field would become a free-text-input in the case where no match is found within the option list... then no, that's a new element entirely. I should never get unexpected field values from a select element.

[gregwhitworth]

Amelia Bellamy-Royds had a great suggestion that we should consider which is that this should be provided by default and not use an attribute nor a new element.

My preference is still to make this the default behavior without any markup change. This is a user convenience, that doesn't change the behavior for the website code, and I really can't imagine any reason why a website would want to prevent it.
But if not that, then attribute.

original tweet and there is a decent amount of support for this. And then if you consider that the data above shows that 7/9, whether they be a <select> or a <combobox> it supports that this is a common paradigm and should be considered to be a default.

https://twitter.com/AmeliasBrain/status/1272720058431594496

[keithjgrant]

My inclination is to modify <select> because you can start using it immediately with graceful degradation built in.

…UNLESS <combobox> would be style-able out of the gate, in which case that would be a huge win

[AmeliaBR]

One other thing to mention is that Firefox already has an experimental implementation of a search-filter feature for select elements. (Enabled by the dom.forms.selectSearch flag in about:config).

I don't think the Firefox widget is a best pattern yet. (Firefox tracking bug. For one thing, keyboard accessibility seems lacking — I can't figure out how to focus the search field from keyboard alone, and without focusing the search field, it just does regular left-to-right typeahead, instead of filtering.

The Firefox widget also currently only works on drop-down selects. Adding it to multi-line selects (list boxes) would be a little trickier — for web compat, you can't change the layout size of the list, but you also can't change the number of items initially visible, since web page authors may be counting on both of those to match the size attribute predictably. Even for drop-downs, the current Firefox implementation is only adding the search box for long lists.

So maybe there is a value in adding an attribute for an author to request search controls (even on listbox-style selects, or even on short lists), while still allowing browsers to automatically include it where it is clearly the more user-friendly option.

So there is definitely still much to discuss about how best to implement a filterable list selection widget. But compared to the other options (a new element, or a new validation constraint attribute on <input datalist>), I do strongly encourage this to be pursued as an enhancement to <select>. It has the most consistent fallback behavior. Users on new user agents would get the better user experience, but users on older user agents would still be able to select a valid value from the list.

P.S., Here's my demo page, if anyone wants to play around with existing browser implementations of listbox, drop-down select, and combobox (<input datalist>) widgets: https://codepen.io/AmeliaBR/pen/NWGdVVY?editors=1000
The lists are CSS named colors, so if you filter by words like “pink” or “green” or “blue”, you want to see results like “hotPink”, “seaGreen” and “royalBlue”, not just the entries starting with the letters you typed.

[AmeliaBR]

One more thing, since the issue title is broadly “thescope of the select control”:

I also strongly support user agents enhancing the presentation of <select multiple> to make it user-friendly to toggle on and off various options individually (e.g., with checkboxes for each option). Again, this doesn't change the data that is input to the form, but it does make it much easier for the end user to input it! If it can be done without breaking the visual layout, it shouldn't require opt-in from the website markup.

[gregwhitworth]

@AmeliaBR yeah - the primary thing I'm trying to derive from this is "searching" a part of <select> since a combobox's definition is that of a component that has free typing and selection methods. So the date/time control can be considered a type of combobox as you can type in a date as well as select one.

I also strongly support user agents enhancing the presentation of <select multiple> to make it user-friendly to toggle on and off various options individually (eg: with checkboxes for each option)

Yeah, I haven't gotten to the multiple part of the spec but technically the anatomy and model do not change for a select, whether multiple is applied or not. I can't think of any library that changes their structure (eg: layout) when it is applied, but they do adjust behavior - such as adding in a graphical checkbox element, allowing numerous selection which then of course does not dismiss the popup.

Note: *The web platform is only one implementation of an Open UI spec and when changes to HTML are suggested based on the Open UI spec we'll of course need to take into account web compat. This may or may not impact the need to opt-in for searching. While looking at other aspects of the Open UI spec from a web platform perspective we think we'll need an opt-in no matter what. But that's a separate discussion to have in WHATWG.

[una]

I’m not sure I would want this by default. There are many cases where a user would not be aware of the options prior to opening the drop down (ie. company services or packages). Likely those would coincide with a shorter, more digestible list of options. An input with a typing indicator may be confusing in these cases. The filtering mechanism is most useful when a user knows the input value (ie. selecting a country). - Una

…

On Tue, Jun 16, 2020 at 3:18 PM Amelia Bellamy-Royds < ***@***.***> wrote: One other thing to mention is that Firefox already has an experimental implementation of a search-filter feature for select elements. (Enabled by the dom.forms.selectSearch flag in about:config). [image: Screenshot of the Firefox widget. A select box with a drop-down list, with a search input box at the top of the drop-down. The search field has the word “green” and the list contains CSS named colors filtered to only include those with the word “green” somewhere in the name.] <https://user-images.githubusercontent.com/9876129/84814458-c87d4c80-afce-11ea-9aa5-a54994757827.png> I don't think the Firefox widget is a best pattern yet. (Firefox tracking bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1332301>. For one thing, keyboard accessibility seems lacking — I can't figure out how to focus the search field from keyboard alone, and without focusing the search field, it just does regular left-to-right typeahead, instead of filtering. The Firefox widget also currently only works on drop-down selects. Adding it to multi-line selects (list boxes) would be a little trickier — for web compat, you can't change the layout size of the list, but you also can't change the number of items initially visible, since web page authors may be counting on both of those to match the size attribute predictably. Even for drop-downs, the current Firefox implementation is only adding the search box for long lists. So maybe there is a value in adding an attribute for an author to request search controls (even on listbox-style selects, or even on short lists), while still allowing browsers to automatically include it where it is clearly the more user-friendly option. So there is definitely still much to discuss about how best to implement a filterable list selection widget. But compared to the other options (a new element, or a new validation constraint attribute on <input datalist>), I do strongly encourage this to be pursued as an enhancement to <select>. It has the most consistent fallback behavior. Users on new user agents would get the better user experience, but users on older user agents would still be able to select a valid value from the list. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#104 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM5L3CCCWWKVD44273ERSDRW7APRANCNFSM4NS5CDTQ> .

[gregwhitworth]

I’m not sure I would want this by default. There are many cases where a
user would not be aware of the options prior to opening the drop down (ie.
company services or packages).

I don't necessarily disagree that the user benefit probably changes based on the content. But looking across the content libs and OSes they are all on by default (those that offer them of course). Clicking (or invoking) the input achieves the same as the current button to open the popup. So the user can use either approach. And while very limited in capability, the browsers' <select> offer typing to jump to options that match characters so this would be extending the experience of that capability. Based on that consistency I tend to agree with it being on by default.

[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.