Explore `<input>` Element as a child within `<select>` for Combobox

[sudheer-gowrigari]

Following recent discussions and resolutions (https://github.com/openui/open-ui/issues/939#issuecomment-1910837275) around the combobox anatomy, this issue aims to explore the potential benefits and implications of integrating an <input> element as a child of the <select> element, which could potentially enable us to achieve all the functionalities of a combobox.

[zcorpan]

<input> in <select> is not web compatible, it needs to close the select. See https://github.com/whatwg/html/issues/10310

HTML has input+datalist for combobox. While there are many issues with it, they might be solvable.

[lukewarlow]

@zcorpan input + datalist and an input inside of select aren't necessarily always the same bahaviour though. At least I envisage one to be open ended with suggestions and one to be bounded where the input is doing filtering on a fixed set?

Having said that if it's not web compatible we'll need a different idea. Maybe a texarea (bit odd ergonomically but if it's web compatible?)

[css-meeting-bot]

The Open UI Community Group just discussed Explore `<input>` Element as a child within `<select>` for Combobox, and agreed to the following:

• RESOLVED: the input should not be allowed within the select. The combobox should be implemented as a new element or as part of e.g. input/datalist.

The full IRC log of that discussion

<hdv> Sudheer: when we were discussing combobox recently, we talked about having programmatic support for showPicker
<hdv> Sudheer: which would show a datalist
<hdv> Sudheer: then the discussion started 'do we really need a combobox el?'
<Luke> q+
<masonf> q+
<hdv> Luke: to clarify, are you looking for input in the button/trigger or in the popover?
<hdv> Sudheer: I believe in the combobox not the button
<masonf> ack luke
<hdv> s/for input/for an input
<hdv> Luke: so could be child of datalist? if it's inside a select, according to Simon it's almost certaintly not web compatible
<brecht_dr> q+
<hdv> Luke: if we allow everything in the select without requirements it's potentially not web compatible, so we probably need to keep some of the restrictions
<hdv> Luke: so probably can't have the input as it would close the select
<hdv> Luke: but that's not to say we can't have any text input elements
<hdv> Luke: like textarea
<hdv> Luke: searchable selects are quite a common thing… reason people don't use the select element today I think is that they want a way for users to filter inside of it
<hdv> masonf: there is def this existing compat issue
<hdv> masonf: semantically a select is to select something out of a list of options
<hdv> masonf: a combobox is not that
<hdv> masonf: for accessibility, doing things like putting an input inside of a button or interactive components inside of a select is bad
<hdv> +1 to masonf's point
<hdv> ack me
<masonf> ack mason
<masonf> ack brecht
<hdv> brecht_dr: double checked in a codepen that an input inside of a datalist breaks the page
<masonf> q+
<hdv> [brecht shared https://codepen.io/utilitybend/pen/GRaqwBx/69e1615519986b0a8792f43eb8adc39e]
<hdv> brecht_dr: creating something accessible out of a select like this is difficult, eg feedback when no options are available. So seems to be that a new option is better
<hdv> s/option/element
<masonf> q?
<hdv> masonf: in our compat research we did see that very very few people put an input inside of a datalist… input inside of select is more common
<masonf> ack masonf
<Luke> q+
<masonf> ack luke
<masonf> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
<hdv> Luke: to clarify, is a combobox from an accessibility point of view unbounded? there's search for select which is fixed set of options that you can filter… then input datalist which is unbounded for selections
<hdv> Luke: I don't know how that works semantically, are they both types of combobox?
<masonf> https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/select_role
<hdv> Luke: having bounded and unbounded be different elements seems sensible
<hdv> Luke: for select we can reuse the existing thing, for input datalist we probably can't?
<brecht_dr> q+
<hdv> Luke: does datalist on its own have compat issues?
<hdv> masonf: problem would be sites that count on it being ignored and it no longer being ignored
<masonf> ack brecht
<hdv> masonf: there is a combobox role, explicitly unbounded input, and select role, they are separate roles
<keithamus> q+
<hdv> brecht_dr: changing how a datalist works is dangerous, people throw a lot of CSS at things that don't support CSS… that might break things
<dbaron> (I think one problem in this space is that the term "combobox" has been used for a few somewhat different things.)
<masonf> ack keith
<hdv> +1, dbaron!
<hdv> keithamus: is the combobox role explicitly unbounded?
<hdv> keithamus: select is bounded today in the sense that you currently can't add an input in?
<hdv> masonf: programatically you can do it today, but not sure if that confuses AT
<masonf> q?
<hdv> Luke: if an input is inside of a select it should be in the popover I think
<hdv> masonf: heard clearly adding input in the button would be very bad for accessibility
<masonf> proposed resolution: the input should not be allowed within the select. The combobox should be implemented as a new element or as part of e.g. input/datalist.
<Sudheer> +1
<brecht_dr> +1
<hdv> +1
<keithamus> +1
<dandclark> +1
<masonf> RESOLVED: the input should not be allowed within the select. The combobox should be implemented as a new element or as part of e.g. input/datalist.
<hdv> Luke: filterable selects are a thing… that would presumably involve having an input inside of a select, but would be in the popover of the select?
<hdv> masonf: it's a good question, but that applies to select but talking comboboxes here
<hdv> masonf: also quesiton is if it can be done accessibly
<hdv> s/quesiton/question