[combobox] Is type="selectlist" correct for the input?

[lukewarlow]

I feel like adding a new input type doesn't really add anything?

Search feels appropriate?

[lukewarlow]

Alternatively I reckon at least call it combobox not selectlist. While they're similar they are distinct components.

[sudheer-gowrigari]

@gregwhitworth Let's use this issue for discussing all elements of combobox anatomy.?

[lukewarlow]

Thinking on this some more I think combobox should allow any type the user wants inside of its input. As the type attribute provides relevant validation.

If I want a telephone input that drops down with previously saved examples I want to get the free validation? (Might be a bad example I don't think telephone actually provides validation but you get the general idea)

[sudheer-gowrigari]

@lukewarlow In the case of selectlist the type=selectlist attribute indicates to the browser that this button should open the listbox. We need some kind of similar thing(either a unique attribute or type) even for combobox no?

[lukewarlow]

The key difference is selectlist is designed to support multiple buttons (split button design)
Whereas if someone puts 2 inputs into combobox they're asking for shenanigans and that's exactly what they'll get 😂.

[css-meeting-bot]

The Open UI Community Group just discussed [combobox] Is type="selectlist" correct for the input?, and agreed to the following:

• RESOLVED: the first button inside <select> triggers the popover. If there is more than one, use <button type=popover> to be the one that triggers the popover.

The full IRC log of that discussion

<jarhar> luke: current explainer for combobox uses type=selectlist for the input
<jarhar> luke: selectlist is no more so that name is incorrect regardless
<masonf> q+
<jarhar> luke: if select still exists then thats wrong because its not a select or selectlist
<jarhar> luke: so i thought it should be type combobox, but the more i thought about it, the idea of requiring a certain type on the input actually makes sense
<gregwhitworth> q+
<jarhar> luke: it has builtin stuff like there are separate attributes that do this
<jarhar> luke: you might have a dropdown combobox and its for urls, and you want it type=url, or telephone numbers or anything like that where you want to use a builtin input type, so prescribing one doesnt make sense
<gregwhitworth> ack masonf
<brecht_dr> q+
<scotto> q+
<jarhar> masonf: we should follow the model of form in two ways. if you put a button in a form, then that button doesnt need a type and it will submit the form for you. if you have multiple and theres ambiguity then you need to put type on one. in this case i would say type=popover since you get a picker
<jarhar> gregwhitworth: i agree
<jarhar> gregwhitworth: were going to have this same problem for date, color, all of them
<jarhar> gregwhitworth: i like popover as well
<gregwhitworth> ack gregwhitworth
<dbaron> i/luke: current explainer for combobox/ScribeNick: jarhar
<jarhar> brecht_dr: i wonder if it is confusing in some way, select in some way also triggers a popover, or is that too simplistic
<dbaron> Regrets: hdv
<gregwhitworth> ack brecht_dr
<jarhar> masonf: precisely, in a select youre going to trigger a popover, so lets use it there too
<gregwhitworth> ack scotto
<jarhar> scotto: in the future, html will tell us we already have a combobox, why cant you just put this inside a wrapper and you already have a datalist you can style it, conversation about select now
<gregwhitworth> q+
<luke> q+
<jarhar> scotto: do we need type on input elements or can we just use the list attribute to point to a popover, is that what were doing here?
<jarhar> gregwhitworth: thats a valid argument. it is accomplishing the same thing. less the combobox scenario, but what we were trying to do - select is going to be the same way, so what if we have a date input or color that are extensible
<jarhar> gregwhitworth: i agree with you on the combobox one, i wonder if the same statement holds true for select
<jarhar> masonf: the problem with the input is that you cant have children inside the input
<jarhar> masonf: i like that were thinking forward, but i like crossing one bridge at a time
<jarhar> masonf: lets add an attribute to input that allows it to have children
<jarhar> scotto: but does it need to have children? depending on the platform, select is a combobox
<bkardell_> masonf: is there any precedent for parsing differently based on an attribute?
<jarhar> scotto: inserting a button or datalist in select, what the accessibility mappings for that is ignore the select element and go to its children in those cases because you cant have a combobox that has a button inside of it - theyre siblings, not descendants
<jarhar> masonf: the accessibility mappings can be done either way though
<jarhar> scotto: but even for the inputs that do have browser nested buttons inside of them, theres buttons inside the shadowdom
<jarhar> masonf: youre right, the input element has shadowdom and it contains buttons in the same way that were proposing the select element
<jarhar> masonf: the weird one is where theres an idref and youre connecting things in the dom
<gregwhitworth> q+
<jarhar> scotto: do we need to undo conventions and allow for nesting things that up to this point werent allowed when we could just have them be siblings instead
<jarhar> masonf: one is backwards compatability
<jarhar> masonf: one thing that nesting datalists is that it allows old browsers to still work
<gregwhitworth> ack luke
<jarhar> luke: my dream would be that html doesnt have void elements, thats not going to be a thing
<jarhar> luke: its weird that you cant nest children inside certain elements
<bkardell_> xml5?
<jarhar> luke: it would make lots of styling things easier
<masonf> <input allowschildren type=text>
<jarhar> luke: if we could have an attribute that lets you nest stuff inside of input, that would be great
<jarhar> luke: i dont know if you can switch something being void or not based on an attribute
<jarhar> luke: your original response mason is that if we have the type be popover, that then limits stuff like the ability to do type email
<jarhar> luke: you want the combobox to be a dropdown of emails, you cant have builtin validation and native keyboard @ symbol
<jarhar> luke: which is something you do get when you allow any type
<jarhar> luke: today, you can have any type you want and attach it to a datalist
<jarhar> luke: i dont think the combobox should remove that capability
<jarhar> luke: you would get styling but then have to do more stuff yourself
<gregwhitworth> q?
<jarhar> luke: if you could have input type date with suggestions in combobox that would be a good thing
<jarhar> masonf: we are talking about select with a button and the type of that button
<jarhar> masonf: the second thing is customizing an input like a type email
<jarhar> masonf: youre right you cant use type popover and type email
<jarhar> masonf: i wonder if the solution to that is to have input type email with an attribute that allows it to have children. the button would have type popover
<jarhar> masonf: i wonder if we're crossing two things
<jarhar> gregwhitworth: we are, and that is the problem with the issue
<jarhar> gregwhitworth: combobox was very much 90ish percent of a combobox is an extension of a dropdown or select
<jarhar> gregwhitworth: we just copy the shadowdom and paste it in
<jarhar> gregwhitworth: at the time it was that selectlist and thats how the invoker happened
<jarhar> gregwhitworth: i would prefer to just resolve on select since its a known quantity at the moment
<jarhar> gregwhitworth: this has a title of combobox, it was trying to carry over the learnings of select. if we resolve on select, then as we work on combobox we can account for the other things
<jarhar> gregwhitworth: theres a lot of things untangled, we can set the judicial precedent
<jarhar> gregwhitworth: this issue may not be relevant when we do combobox
<jarhar> luke: i worry that type=popover may be confusing
<jarhar> luke: button popovertarget is a standalone thing, and now youve got button type=popover which is changing the type attribute in this one specific place
<jarhar> luke: kind of makes you wonder why does button type=popover - is that not how popovers worked in the first place
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<jarhar> luke: for now we could resolve on type popover and we could come back to it
<jarhar> q+
<jarhar> masonf: we have to rename everything 3 or 4 times, this will get one of them out of the way
<gregwhitworth> ack jarhar
<dbaron> ScribeNick: gregwhitworth
<gregwhitworth> jarhar: I was going to say, I agree that we'll need to pick this then take it up to WHATWG and the way that I'm going to tackle it is we need split button
<gregwhitworth> jarhar: and we need to be able to differentiate between the two. Then people will want to do it another way and I can see things going that
<dbaron> ScribeNick: jarhar
<jarhar> masonf: we might need to back off on split button and then type select goes away entirely
<dbaron> s/we might need to/jarhar was saying that we might need to/
<masonf> Proposed resolution: the first button inside <select> triggers the popover. If there is more than one, use <button type=popover> to be the one that triggers the popover.
<luke> +1
<keithamus> +1
<masonf> RESOLVED: the first button inside <select> triggers the popover. If there is more than one, use <button type=popover> to be the one that triggers the popover.

[sudheer-gowrigari]

The Open UI Community Group just discussed [combobox] Is type="selectlist" correct for the input?, and agreed to the following:

• RESOLVED: the first button inside <select> triggers the popover. If there is more than one, use <button type=popover> to be the one that triggers the popover.

The full IRC log of that discussion

We would like to reopen this discussion with reference to this earlier comment. We believe the combobox should include:

• An input field with a "text" type for user entries.
• A button to display the selected option.
• An optional button to trigger a popover when clicked ⬇️.

<input type="text"> 
    <button><selectedoption></selectedoption></button>
    <button type=popover>⬇️</button>
</input>

Examples from Twitter and Facebook, where typing/clicking in the input field automatically triggers a popover.

twitter.mov

Screen.Recording.2024-04-15.at.7.44.40.PM.mov

[css-meeting-bot]

The Open UI Community Group just discussed [combobox] Is type="selectlist" correct for the input?.

• RESOLVED: A combobox will have a button so that the datalist is shown. Extend datalist to have programmatic support for showPicker() to allow for hiding of the button when desired.

The full IRC log of that discussion

<hdv> gregwhitworth: Luke was updating the explainer for selectlist… this intertwines with other issues in invoker, that we only support buttons and anchors
<hdv> gregwhitworth: the problem that we found when we looked at a bunch of comboboxesis that many of them don't have buttons… like Facebook and Gmail… they have buttons but those have different functions
<hdv> gregwhitworth: so sidestepping thinking about HTML… technically you would want input type=text with children available, but what we're trying to put forward is that input type=text is the one opening the popup within the combobox
<keithamus> q+
<hdv> gregwhitworth: TLDR what type should this be?
<gregwhitworth> ack keithamus
<brecht_dr> q+
<hdv> keithamus: we already have input with datalist… I wonder if that's something to explore…are they two different patterns? I genuinely don't know the answer to that question
<hdv> gregwhitworth: we cover that at the base of the doc… happy to have this debate as we'll probably have it elsewehre… can you do this today, yes you can bind two elements today, but the combobox can do it out of the box?
<scotto> q+
<gregwhitworth> q+
<hdv> keithamus: looking at it through a different lense… it's turning text input into a combobox vs doing it with buttons… eg what does this new thing do that input and datalist don't? I get it is terrible to style today, but is trying to improve how that works worth exploring?
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: I think datalist has been mentioned a few times more in the group… that we want more style functionality… I would be all for that
<keithamus> q+
<hdv> brecht_dr: with combobox you're searching for something, would a search type input make sense? eg on mobile device in some cases you would get a specific type of keyboard?
<gregwhitworth> ack scotto
<hdv> scotto: re what Keith was saying before… seeing the the way that selectlist element is now just select element… I could see that might happen with this too
<hdv> scotto: if we really want HTML to allow for better styling, we need to threaten them that we want a new element
<hdv> scotto: I like the idea of having a combobox element
<hdv> scotto: but you can really have comboboxes that have different purposes
<hdv> scotto: browsers right now treat a lot of native text fields as comboboxes because of autocompletion that pops up in a lot of elements
<hdv> scotto: having the new combobox element would be a good way of mitigating the potential conflict between browser comboboxes in today's text inputs vs the new thing
<hdv> gregwhitworth: good points
<hdv> gregwhitworth: the anatomy gets drastically updated, basically like a copy of select
<hdv> gregwhitworth: I'l argue in many instances this is the most commonly used element; you can type but you can't see hwat you're typing
<jarhar> q?
<hdv> gregwhitworth: HTML is an implementation detail… the key things of why we need this: irrespective of what type we set this to, we need to be able to set children for a variety usecases, eg email addresses in email client or labels on GitHub
<hdv> gregwhitworth: we expect datalist to become more styleable because it being used in select
<hdv> gregwhitworth: so now a complex textfield with contenteditable and children below it… how do we invoke the popup?
<hdv> gregwhitworth: whether it's type search or type text… for the holy grail of being able to set children, that's a long way
<hdv> gregwhitworth: I'd need something beyond button or anchor to cover these kinds of use cases
<hdv> keithamus: I think input is a non starter, because it is not backwards (or forwards) compatible…
<hdv> keithamus: having input type=whatever, the shape of that HTML is not really tenable…however… the screen recordings attached to this issue are of searches… the presented dropdowns are effectively autocompletes
<hdv> keithamus: which are different from a bounded box of options of which you must select one
<hdv> keithamus: vs search is looking through potential searches to complete
<hdv> gregwhitworth: that takes me back full circle… if you'd build this, what would it be if not input type=whatever?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<brecht_dr> q+
<hdv> keithamus: sounds fun if invokers invoke datalist… seems like a reasonable extension… I'm fuzzy on it but there is a valid diference between a select and a datalist that does the autocomplete aspect
<gregwhitworth> q+
<hdv> keithamus: the search example is the only presented that doesn't have a button to open it… are there others, or if it's just search can we find some other solution to it?
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: a new element seems like a more logical approach because there are more options and possibilities in what people want from a combobox, eg the way it searches and behaves, there are many more edge cases in a combobox than there are in a styleable select
<hdv> brecht_dr: this seems to be as one of those things that should be a new element
<hdv> gregwhitworth: I feel like we're starting to determine how this implemented in the browser, and that's the part we'er starting to struggle
<keithamus> q?
<hdv> gregwhitworth: do you think we can resolve this with invoker on an input type=text that invokes a datalist?
<hdv> keithamus: doesn't even need to be invokers, not sure if it exists today, is there a way to programmatically open a datalist?
<hdv> keithamus: if that doesn't exist that seems like a great first thing to loko at
<hdv> s/loko/look
<hdv> keithamus: people don't use datalist today because it's not great to style… but that doesn't really help solving the combobox use case
<hdv> keithamus: you would need some kind of attribute to say this element is open and takes descendance, to not trip up the parser?
<hdv> keithamus: a combobox is a lot of things smushed together, A B and C… the search has A B but doesn't make it a combobox?
<scotto> q+
<hdv> gregwhitworth: a set of options plus a text field but now I can see what I'm typing?
<gregwhitworth> ack gregwhitworth
<hdv> keithamus: there's two things… one is here's the thing you're allowed to pick from, but combobox is very free form
<gregwhitworth> q?
<gregwhitworth> q+
<hdv> keithamus: so I'm not compelled enough to feel like presenting search as the smoking gun that needs to change the design
<hdv> keithamus: are there similar form designs that aren't search that don't have the button
<gregwhitworth> ack scotto
<hdv> s/button/button?
<hdv> scotto: the reason I went on the queue … why does the invoker need to be on the input… why could it not by default have a button?
<hdv> scotto: like with popover, authors may in the future be using it without having to use it themselves
<hdv> scotto: for most things authors want to do we want them to use buttons to invoke
<hdv> gregwhitworth: seems we're a friction point… what author can build vs HTML
<hdv> gregwhitworth: if this could use invokers under the hood without allowing authors to use invokers on inputs… I think I'm a bit more ok with it, but tricky to put in the explainer document like that
<hdv> gregwhitworth: now that you explain it like a spectrum, keithamus, I understand where you're coming from
<scotto> just as a related concept - in ARIA there are a number of abstract roles that are useful for browser implementors - but are never meant to be used by authors
<hdv> gregwhitworth: key difference is that it's going to be unbounded content… but am willing to putn on that… let's initially put a button in there, I don't think it would become backwards incompatble if we did
<keithamus> q+
<hdv> gregwhitworth: but raises accessibility problems if we remove that button…
<gregwhitworth> ack gregwhitworth
<hdv> keithamus: more thoughts on hiding the button… adding the button and setting it to display none…if there's something the browser can do that platforms cannot, don't see why we coulnd't add programmatic API
<hdv> keithamus: it doesn't need to be declarative, that's an enhancement we can do with JavaScript… there's showPicker() today
<gregwhitworth> Proposed Resolution: A combobox will have a button so that the datalist is shown. Extend datalist to have programmatic support for showPicker() to allow for hiding of the button when desired.
<hdv> keithamus: do we want to talk about combobox?
<keithamus> +1
<hdv> gregwhitworth: this is assuming prior resolution that Open UI want a combobox
<scotto> +1
<brecht_dr> +1
<gregwhitworth> Resolved: A combobox will have a button so that the datalist is shown. Extend datalist to have programmatic support for showPicker() to allow for hiding of the button when desired.