[css-forms-1] Should `appearance: base-select` work on listbox selects? (`<select size>`/`<select multiple>`)

[LeaVerou]

<select> can be rendered as either a dropdown or a listbox, when either size or multiple is set. Setting aside the fact that this was a terrible design choice that confounds unrelated concepts (that ship has sailed…), it appears that the newly shipped implementations of appearance: base-select do not account for these presentations of <select>.

For example, this is a fork of Chrome’s base-select demo from this article, with size="3" added to it. Suddenly, all the new parser goodness is gone.

The current draft has precious little on listboxes:

• Only a ::picker-icon pseudo-element defined for <select>, with no mention that this doesn't apply to listboxes
• The only mention of listboxes seems to be a reference to issue [selectors] Add pseudo-classes for <select> being a drop-down box vs a list box #7422

Given that base-select has shipped fairly recently, and is a feature that authors are very excited about, I think this is high priority since otherwise we may be locked in to preserving the current behavior for web compat reasons.

[lukewarlow]

Fwiw the answer is definitely, yes it should work. If you try chrome canary with experimental features there's an implementation to try out that mostly works. I think the biggest holdup is

<select multiple size=1> and how that should render and work.

[mfreed7]

@josepharhar

[josepharhar]

Thanks Lea! As Luke mentioned, I have implemented this in chromium and I am planning on making spec changes in WHATWG to support this. Please let me know if you have any feedback about the experimental chromium implementation.

[css-meeting-bot]

The CSS Working Group just discussed [css-forms-1] Should `appearance: base-select` work on listbox selects? (`<select size>`/`<select multiple>`), and agreed to the following:

• RESOLVED: appearance: base-select can be used to opt listbox selects into base appearance. control of listbox and multiple rendering will be improved in html
• RESOLVED: appearance: base-select can be used to opt listbox selects into base appearance. control of listbox and multiple rendering will be improved in html

The full IRC log of that discussion

<kbabbitt> lea: recently appearance base-select shipped in chorme for customizable select
<kbabbitt> ... however current impl doesn't do anything for listbox selects
<kbabbitt> ... and there's nothing in the spec around this
<kbabbitt> ... there's a picker-icon pseduo which theoretically doesn't apply
<kbabbitt> ... only mention of listboxes is an unrelated mention around ? pseudo classes
<kbabbitt> ... question is, should appearance: base-select apply to listbox select
<kbabbitt> ... one idea I had is that, even though we have consensus that it should, i wonder if we introduce a different value for this
<kbabbitt> ... we could use the css property to switch between the two modes
<kbabbitt> ... right now there's no css way to switch
<keithamus> q+
<kbabbitt> ... internal parts and dom are so different between the two modes, I'm not sure how it would work without such a toggle
<kbabbitt> ... pseudo elements are different
<kbabbitt> ... from an architectural point of view it was a mistake that the same element does both
<kbabbitt> ... and things that have nothing to do with it are used to switch between them
<kbabbitt> ... most modern uis implement dropdowns from scratch so they can do multi select dropdowns
<jarhar> q+
<kbabbitt> ... perhaps if we had a separate value it could fix all these problems at once
<kbabbitt> ... so I'm not convinced we should have appearance: base-select apply to listbox mode
<kbabbitt> ... wonder if we should have a separate value
<kbabbitt> ... very clear we need a way to style listboxes, not sure if it should be base-select or a different value
<astearns> ack keithamus
<kbabbitt> keithamus: my understanding is that popoover element that would provide list of options
<kbabbitt> ...that can be styled as display:block which would make it part of page flow
<kbabbitt> ... then you'd have a listbox style control
<kbabbitt> ... overlay property would be the one
<kbabbitt> ... so you can put it as part of page flow rather than as popover
<kbabbitt> ... does that satisfy the query?
<kbabbitt> lea: not sure I understand the proposal
<kbabbitt> keithamus: your query is between the two modes, and I don't think they're modes, I think the pseudo elements are the same but you'd effectivaly style the dropdown so it would be part of the page
<kbabbitt> lea: you'll still have the selected content element
<kbabbitt> keithamus: you can omit that or display: none it
<kbabbitt> lea: or we go the opposite way from listbox from dropdown which is more commonly needed
<kbabbitt> keithamus: two modes are, picker element is either popovert or now
<kbabbitt> ... and selected content is either displayed or not
<kbabbitt> lea: downside of that is you need to implement yourselves how dropdown would look for listbox appearance
<kbabbitt> ... you have a listbox and you have to write several css rules to make it look like a dropdown
<kbabbitt> keithamus: one point of base-select is ... [missed] ... you'd have some default styling
<kbabbitt> ... it should be consistent, whether it would be a matter of ... I'm curious why we would need to put effort into .... why an author would need to put effort into making it look native
<florian> q?
<kbabbitt> lea: not saying they want to make it look like listbox widget, saying they want to make it look like a listbox ... not just a matter of a single css rule, would take several
<kbabbitt> ... when you start form a dropdwon, all of the css you have to write is to style it
<kbabbitt> ... when you start from a listbox and want to make it look like a dropdown, now you have to write a bunch more rules
<kbabbitt> keithamus: only difference is form control that opens the picker is the thing that is rendered on the page in a picker mode
<kbabbitt> ... in a listbox mode, the picker is rendered on the page and the button thing is not
<kbabbitt> ... so you're just display:none'ing on the button
<kbabbitt> ... and setting overlay none on picker
<kbabbitt> ... overlay auto on picker and display block on button
<kbabbitt> ... then you can have all your styles separate and they can be consistent
<kbabbitt> ... but maybe joey has some better answers here
<astearns> ack jarhar
<kbabbitt> jarhar: I've been working on an impl of this in Chromium
<kbabbitt> ... I believe that the different modes about listbox and popul and signle and multiple select should be controlled with existing html attributes
<kbabbitt> ... size=1 makes popup, size>1 makes it listbox
<kbabbitt> ... different modes should be controllabe with appearance:base-select
<kbabbitt> ... I don't think we need other values for appearancew
<lea> q?
<lea> q+
<kbabbitt> ... I don't think we need to control multi select or popup with css
<kbabbitt> ... it can be done with HTML
<kbabbitt> ... right now there are some issues liek you can't have select multiple with popup on desktop
<kbabbitt> ... on mobile you can't get a listbox
<kbabbitt> ... these are things I'm working on
<kbabbitt> astearns: jarhar you're saying the answer to the original question in the issue is, yes it should
<kbabbitt> .. answer to lea's new question is "no"
<kbabbitt> jarhar: correct
<astearns> ack lea
<kbabbitt> lea: the issue is not whether multipleness should be controlled by css
<kbabbitt> ... of course it should be controlled by html
<kbabbitt> ... problem is today when you specify multiple in select you always get a listbox, can't get a dropdown
<kbabbitt> ... presumably base-select would get you a styleable dropdown
<kbabbitt> jarhar: planning on separate change so that size=1 on select ? will give a popup
<kbabbitt> lea: regardless of whether you specify base-select? don't know if that's web compatible
<kbabbitt> jarhar: correct, wqill fild out if it's web compatible
<kbabbitt> lea: some data points we're missing for a decision here is how much code would be needed to make a decision here
<kbabbitt> ... would be helpful if keithamus could write snippets in issue to show what switching would look like
<kbabbitt> ... maybe I'm wrong and it's just a couple css rules and it'llo be fine
<kbabbitt> astearns: I think that makes sense, we should take it back to the issue and go through some example code
<kbabbitt> ... thank you jarhar
<kbabbitt> lea: could we have a resolution to [missed]
<lea> s/lea: could we have a resolution to [missed]/lea: could we have a resolution that we want listboxes to be stylable, with the exact syntax TBD/
<kbabbitt> astearns: [discussing what resolution we could take]
<chrishtr> +1 to going with joey's approach and then reconsidering if it is found web-incompatible
<kbabbitt> lea: I'm fine with that
<kbabbitt> astearns: we often take resolutions hoping something will be web compatibvle
<kbabbitt> astearns; jarhar could you summarize resolution for this issue that you plan to implement?
<jarhar> proposed resolution: appearance: base-select can be used to opt listbox selects into base appearance. control of listbox and multiple rendering will be improved in html
<kbabbitt> astearns: does that look okay to you lea?
<kbabbitt> lea: I think so, also concept that size is distinct from whether you want a listbox or dropdown
<kbabbitt> ... how long the dropdown is is a CSS thing but that's secondary
<kbabbitt> astearns: let's go with proposed resolution for now
<kbabbitt> ... any objections?
<keithamus> +1
<astearns> ack fantasai
<kbabbitt> fantasai: reason we use base-select here was to allow for progressive opting in more controls
<kbabbitt> ... and avoiding compat issues
<kbabbitt> ... are concerned about that, or are other controls shipping ?
<kbabbitt> jarhar: I'm personally not concerned about using same keyword
<kbabbitt> ... but I'm open to suggestions
<kbabbitt> fantasai: ok we can go with this
<chrishtr> I think it's fine for both to use base-select. We can reconsider if it is found to be web-incompatible.
<jarhar> RESOLVED: appearance: base-select can be used to opt listbox selects into base appearance. control of listbox and multiple rendering will be improved in html
<kbabbitt> RESOLVED: appearance: base-select can be used to opt listbox selects into base appearance. control of listbox and multiple rendering will be improved in html

[josepharhar]

Here are some examples of how I'm proposing that listbox vs popup rendering should be controlled with html attributes, which I am hoping will be web compatible:

• Does <select multiple> need a button and popup by default? openui/open-ui#1102 (comment)
• Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android whatwg/html#8189 (comment)

[LeaVerou]

So we have consensus that we do need stylable customizable listboxes, yay.

As I mentioned in the call, it is not 100% clear to me whether it should be done via base-select. One idea, which would also address whatwg/html#11452 is to have a separate base-listbox value so that authors can also switch between the two in CSS, since there are use cases for switching between the two.

@keithamus said in the call that, as long as base-select also applies to listboxes, authors can switch between the two already with minimal CSS. He will provide example snippets to demonstrate. My concern is that this would take a nontrivial amount of CSS, so authors would have to essentially recreate the default dropdown appearance before they can apply any styling — which is something the UA already knows how to do, but if it's indeed a matter of 1-3 declarations it's probably fine and not worth the complexity of another appearance value.

@josepharhar said that his plan is to make it so that <select multiple size="1"> is a dropdown (with appearance: base-select or not), web compat permitting. That could address one of the core use cases for switching between the two. OTOH, size is a presentational attribute and it feels wrong to control the listbox height in HTML, but perhaps that could be mitigated by introducing an auto or max value and specifying the actual height in CSS, though I cannot think of a way to do this right now, since with stylable listboxes, options could wrap, so it's not just a height: calc(var(--max-lines) * 1lh).

[josepharhar]

separate base-listbox value so that authors can also switch between the two in CSS

I'd prefer not to implement this because we can't change the DOM in the UA shadowroot based on the computed value of appearance, so we would have to add a lot of hacks to the popover element in the UA shadowroot to make it not really a popover anymore.

as long as base-select also applies to listboxes, authors can switch between the two already with minimal CSS

In my opinion, this is hacky and should not be encouraged. I'm also not sure how minimal it would really be, and I'm not sure if accessibility mappings would work correctly.

size is a presentational attribute and it feels wrong to control the listbox height in HTML

I agree, but creating a new attribute got negative feedback here: whatwg/html#8189 (comment)

[keithamus]

<style>
select { appearance:base-select; width:0px; padding:0; border:0 }
select::picker(select) { appearance:base-select; display:block }
</style>
<select><option>One</option><option>Two</option></select>

This renders the picker element on the page, which acts a little like a list-box. There are some issues, however, as the browser will force the overlay:auto property onto the picker when it is open, and there is currently no way for non-UA style sheets to set overlay:none. This forces the element to the top-layer on click which is a little jarring, so it would require some more (likely non-trivial) CSS to get it working nicely.

I agree with @josepharhar though - the accessibility tree between <select> and <select multiple> are considerably different and it might be difficult to rectify this. I suppose if we had the ability to set overlay:none, the accessibility engine could check if the picker is in the top layer, and if not check if it has layout, and if it does then it is a listbox.