[selectors] Add pseudo-classes for <select> being a drop-down box vs a list box

See whatwg/html#7050

Chromium supports a :-internal-list-box pseudo-class in the UA stylesheet, which matches <select> elements that render as a list box instead of as a dropdown box.

Gecko similarly supports :-moz-select-list-box in the UA stylesheet.

WebKit seems to use attribute selectors instead, although I think it's not entirely accurate since the decision per spec depends on the parsing result of the size attribute. (Demo: <select size="+02xyz">)

Web developers could rely on the multiple attribute being present to target list boxes, but that might not always work so well, in particular if you're writing CSS that should work for arbitrary HTML.

I think it makes sense to add a pseudo-class that matches select elements that are list boxes, e.g. :select-list-box. To match drop-downs, you can do select:not(:select-list-box).

Spec: https://drafts.csswg.org/selectors/

@mfreed7

Is there interest in standardizing this pseudo-class (and make it also available to author CSS)?

cc @mfreed7

Via git blame of WebKit's html.css I found https://bugs.webkit.org/show_bug.cgi?id=220376 -- I think a pseudo-class as suggested here would be less prone to bugs like this (compared to attribute selectors). cc @pxlcoder

Via git blame of Gecko's html.css I found https://bugzilla.mozilla.org/show_bug.cgi?id=1643246 where attribute selectors were replaced with a pseudo-class. cc @emilio @heycam

It certainly seems tricky to select this based on attribute selectors, so I'm supportive of trying to standardize a pseudo class.

Picking a name will be tricky. I'm not sure I like :select-list-box, since in my view, both in-page and pop-up <select>s contain a "listbox". One is just a pop-up listbox and the other is an in-page listbox. Perhaps something like :select-pops-up? Or at least something that refers to the pop-up behavior? Similarly, we need to be careful to distinguish whether this pseudo class refers to whether the listbox pops up or not (as I've assumed), or whether it refers to whether multi-select is supported. Those are (at least theoretically) distinct.

HTML's wording is "list box" for <select multiple> and "drop-down box" for <select>. However those terms are not web-exposed anywhere (prior to this pseudo-class), so they can be changed.

I believe the select element has an aria list box role either way, so that could be confusing.

How about "list box" and "drop-down list box"? (Not sure about "list box" vs "listbox".)

"Drop down" or "drop down list box" seem pretty clear (even though they are "pop up menus" on Mac). But just "list box" by itself is not clear, because I honestly wouldn't remember which one you meant without comparing it to the other term. I think if you had "multiple list box" (or similar*) and "drop down list box" as the two terms, then they'd both be clear, even in isolation.

similar:

List box multiple
Multi-select list box
no-drop list box (clear, but ugh)

It's not necessarily multi-select, though.

<select size=5>
  <option>this is still single-select list box
  <option>foo
  <option>bar
</select>

We could define only a pseudo-class for the drop-down, and rely on the :not() function to match the not-drop-down state.

select:drop-down-list-box {}
select:not(:drop-down-list-box) {}

+1 to the idea of targeting the idea of having a dropdown. Perhaps something like :has-dropdown?

@zcorpan

@zcorpan works for me. I also like the @dbaron refinement. Though there should probably be another dash, like :has-drop-down, so we don’t repeat the nowrap mistake.

Also, would a native date picker or color picker be considered a drop-down, like input[type=date]:has-drop-down?

I’m ambivalent about the extra dash, really.

Also, would a native date picker or color picker be considered a drop-down, like input[type=date]:has-drop-down?

Good question. I would say no. The date widgets are not guaranteed to have a drop-down or a popup, it would be conforming to have a control with only spinners, for example. The color well is specified to have a "color picker" that is separate from the color well, but nothing says it has to be a drop-down. Firefox on macOS opens a popup window for the color picker.

Since the need is specific to the select element, I think we should define it to only apply to select. Should the naming be different because of that?

A few names to consider

:has-dropdown
:select-has-dropdown
:select-with-dropdown
As above but with a dash in drop-down

Example usage:

select:has-dropdown { ... }
select:not(:has-dropdown) { ... }

select:select-has-dropdown { ... }
select:not(:select-has-dropdown) { ... }

select:select-with-dropdown { ... }
select:not(:select-with-dropdown) { ... }

or without type selector (when not using :not())

:has-dropdown { ... }
select:not(:has-dropdown) { ... }

:select-has-dropdown { ... }
select:not(:select-has-dropdown) { ... }

:select-with-dropdown { ... }
select:not(:select-with-dropdown) { ... }

It is probably better in terms of ergonomics to have two pseudo-classes for the two states, e.g.:

:has-dropdown and :no-dropdown
:select-has-dropdown and :select-no-dropdown
:select-with-dropdown and :select-without-dropdown

Since it will only match select elements it seems reasonable to include it in the name, as people may expect :has-dropdown to apply to other things with dropdowns and :no-dropdown to apply to almost all elements.

It seems to me that if this is only ever going to apply to <select>, then it should have "select" in the name. Otherwise, this feels confusing:

input[type=date]:has-dropdown { doesn't match, even when the date picker "drop down menu" is present }

As for :has-dropdown and :no-dropdown - isn't that exactly why we have :not(), to avoid the need for that?

I vote for :select-with-dropdown, because "with" indicates the <select> comes with a drop-down. Somehow (and I'm not sure why) but :select-has-dropdown sounds to me like it should apply only when the dropdown is open. Like it currently has a dropdown.

Interesting side reading on "drop-down" vs "dropdown": https://www.chicagomanualofstyle.org/qanda/data/faq/topics/HyphensEnDashesEmDashes/faq0153.html. Perhaps we should use "menu" instead?

The CSS Working Group just discussed Pseudo-classes for drop-down vs list box for <select>.

The full IRC log of that discussion

<fantasai> Topic: Pseudo-classes for drop-down vs list box for <select>
<fantasai> github: https://github.com//issues/7422
<fantasai> zcorpan: Proposed pseudo-class for <select> elements
<fantasai> zcorpan: it's implemented in both Gecko and Chromium for their UA styles, under a vendor prefix
<fantasai> zcorpan: WebKit doesn't implement the pseudo-class, instead uses attribute selectors
<fantasai> zcorpan: and they have some bugs because of that, because hard to get the details right
<fantasai> zcorpan: so I think there's agreement in the issue that we should have this pseudo-class
<fantasai> zcorpan: and just need to settle thenaming
<emilio> q+
<zcorpan> :select-with-dropdown and :select-no-dropdown
<fantasai> zcorpan: :select-with-drop-down and :select-no-dropdown
<heycam> the WebKit UA style rules: https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/css/html.css#1078-1092
<astearns> ack fantasai
<emilio> fantasai: haven't read the issue, was the bug in webkit about parsing the size attribute as int?
<fantasai> zcorpan: It's parsing the size attribute correctly, the UA style sheet has an approximation of what the HTML results are
<fantasai> zcorpan: so some edge cases will get wrong UA styles
<fantasai> zcorpan: get a drop-down widget, but UA style thinks it should be a list box
<fantasai> zcorpan: so a bit of a mismatch
<emilio> fantasai: asking because it's the way the ua parses integers not being replicatable in css
<emilio> ... maybe we want to introduce a way of selecting based on whether the attr is parsed correctly as an integer
<emilio> ... that's been requested and more generally useful
<heycam> q+
<fantasai> zcorpan: I guess it would be possible
<emilio> zcorpan: guess it would be possible
<fantasai> zcorpan: complication because HTML has multiple number attributes
<fantasai> zcorpan: It has integers and signed integers and floats
<fantasai> zcorpan: I guess CSS could have those as well
<fantasai> zcorpan: but CSS numbers are normally parsed differently from HTML numbers
<emilio> fantasai: we could make it the same or have a flag
<dbaron> "The display size of a select element is the result of applying the rules for parsing non-negative integers to the value of element's size attribute, if it has one and parsing it is successful. If applying those rules to the attribute's value is not successful, or if the size attribute is absent, then the element's display size is 4 if the element's multiple content attribute is present, and 1 otherwise." is the relevant quote from
<dbaron> https://html.spec.whatwg.org/multipage/#concept-select-size
<fantasai> zcorpan: Still seems more difficult to use as Web developer compared to pseudo-class
<fantasai> zcorpan: there's also the multiple attribute
<astearns> ack emilio
<fantasai> emilio: I don't think it's a bad idea, but do we really need 2 pseudo-classes instead of one?
<fantasai> emilio: would rather have single one, they're mutual exclusive
<fantasai> emilio: assuming it's <select>-specific
<fantasai> emilio: using select:listbox and select:not(listbox) would be nicer
<fantasai> zcorpan: I think that's an okay outcome, biggest difference is you need to include a type selector to match the :not() state, whereas with pseudo-classes can only use the pseudo-classes
<emilio> fantasai: we need to consider that we keep adding pseudo-classes
<emilio> ... if we don't really need a pseudo-class
<emilio> ... it's better not to have it
<emilio> ... so that there's less for people to memorize
<emilio> q+
<emilio> zcorpan: agreed
<astearns> ack heycam
<emilio> fantasai: if we can do this with integer parsing and it's not too tricky maybe that's a better way around it
<TabAtkins> In particular, if this is <select>-specific, then its name should be pretty <select>-specific, not generic. Probably means it needs a "select" in the name. But then it's just awkward to have to specify select again, like `select:not(:select-with-dropdown)`
<fantasai> heycam: I'm not strongly against adding pseudo-classes, but wondering if really that useful to expose to authors
<fantasai> heycam: if WebKit wants to fix compat issues, they can have an internal pseudo-class like other engines
<fantasai> heycam: but for authors, thinking whether they are using listbox or dropdown, is something they know ahead of time
<fantasai> heycam: I think it's rare for pages to switch between the two, so don't know how useful it is for authors to have different styles depending on this
<fantasai> heycam: or need to rely on the flexibility of how HTML parses these attributes, vs knowing through the DOM already
<fantasai> <fantasai> +1
<fantasai> zcorpan: for cases where dev controls both markup and CSS, but that's not always the case
<fantasai> zcorpan: maybe you're writing a stylesheet for a design system, want to apply to all WordPress pages
<fantasai> zcorpan: you don't know what HTML they will use
<astearns> ack emilio
<fantasai> zcorpan: so that's why pseudo-class makes sense
<fantasai> emilio: Was going to make similar comment to heycame
<fantasai> emilio: we should encourage use of multiple attribute, it's easy to write selectors for that
<fantasai> emilio: rather than relying on parsing of size attribute
<fantasai> emilio: if you're making design system, ask them to use that
<fantasai> emilio: but I'm on the edge on whether it's worth having a pseudo-class for this or not
<fantasai> zcorpan: multiple is a semantic difference
<fantasai> emilio: sorry, yes, you're riht
<fantasai> s/riht/right/
<fantasai> zcorpan: you can have a listbox that's not multiple
<emilio> fantasai: doesn't seem to me like the selector for this would be that difficult if we had number parsing
<emilio> ... is [multiple] plus size parsing as an integer >1
<emilio> ... the details of how to parse invalid size attributes is a concern for implementors but not authors
<fantasai> zcorpan: type out the two selectors?
<TabAtkins> `select[size > 1], select[multiple]`
<emilio> ... people usually don't write junk in their size attribute
<emilio> `select:is([multiple], [size]:not([size="1"]))` is probably close enough in practice today
<fantasai> `select:not([size>1],[multiple])`
<astearns> ack dbaron
<fantasai> dbaron: One, I tend to agree that if you're building a design system, you probably want these sorts of things
<fantasai> dbaron: I think part of the reason we don't see much demand is that select is so hard to style, don't run into this problem much
<fantasai> dbaron: if styling select worked more reliably, they would want on this more
<fremy> +1 to what dbaron just said, styling select is a pain
<fantasai> dbaron: Quoted HTML, which defines the display size of a select element
<fantasai> dbaron: condition for a Budugbox vs listbox is display size being equal to 1 or not
<fantasai> zcorpan: or multiple attribute being present or not
<fantasai> dbaron: There's a few reasons the selectors above are wrong
<fantasai> dbaron: one is that you need to test for size being zero
<fantasai> dbaron: because HTML applies rules for non-negative integers
<fantasai> dbaron: you want a valid size that is zero or 2 or more
<fantasai> dbaron: or the multiple attribute
<astearns> q?
<fantasai> dbaron: it's doable if you had HTML non-negative integer parsing
<fantasai> dbaron: but might be worth having this pseudo-selector anyway
<fantasai> TabAtkins: fantasai's point was that dealing with invalid things is the sort of things that UA needs to care about, but page author doesn't
<fantasai> TabAtkins: if they're putting random trashi in their size attribute, that's their problem
<heycam> +1 to if we do have a way to do this, would rather a specific pseudo-class rather than a general integer parsing selector
<fantasai> TabAtkins: but HTML UA needs to deal with all kinds of random trash
<fantasai> dbaron: As you go further down the stack to style sheets meant to apply to more and more pages, get closer to needing to match implementation
<fantasai> dbaron: bootstrap might get bugs on this
<fantasai> TabAtkins: Bootstrap can say, "don't write random trash in your size attribute and this will work correctly"
<fantasai> TabAtkins: if we were stricter in parsing this earlier we wouldn't have this problem for UAs
<fantasai> TabAtkins: but even widely-used library, nobody needs to deal with this much trash
<fantasai> TabAtkins: put a number here, and it works. Put a non-number here and it'll not work
<fantasai> fremy: Authors shouldn't have to read the spec to figure out the conditions
<fantasai> fremy: of course they can copy some weird code, but not very understandable
<fantasai> fremy: you will copy and paste it, but not clear what it does at first sight
<fantasai> fremy: if already implemented in engines, have this pseudo-class
<fantasai> fremy: that sounds useful so why not
<fantasai> fremy: why are we wasting time discussing if it's just removing a prefix in the code, seems silly
<astearns> ack fantasai
<fantasai> astearns: We started with what we called a pseudo-class, and now discussing maybe not having pseudo-class
<fantasai> astearns: with arguments presented so far, anyone convinced we should have it?
<fantasai> heycam: me
<fantasai> astearns: Should we try to resolve to add pseudo-class?
<fantasai> fantasai: I'd like to hear from Rachel Andrew and emeyer
<fantasai> fantasai: if they are like, "Yes, we should definitely have this!" then great
<emilio> FWIW this is how Gecko used to implement this with attribute selectors: https://hg.mozilla.org/mozilla-central/rev/13062d9979d254481851c0f8c9d9e608d91f6ae3
<fantasai> fantasai: If not, I'm skeptical
<rego_> there has been a lot of research about styling select in openUI, does anyone know if this topic was discussed?
<fantasai> emeyer: It's hard for me to say, a pseudo-class mostly feels correct here, but fantasai is correct, we have so many pseudo-classes now
<fantasai> emeyer: even more than I realized until recently
<fantasai> emeyer: So I'm not sure I'm 100% convinced that it's best
<fantasai> emeyer: Some way of doing this is good
<fantasai> emeyer: but whether it should be a pseudo-class or ???
<fantasai> fantasai: We would add number-based attribute selectors, and you would make a selector
<fantasai> astearns: It would be a copy-paste incantation
<fantasai> fantasai: still have to do that if it's a pseudo-classs!
<emilio> Another interesting edge case is `size=""`
<heycam> emilio, similar but not exactly the same as the current WebKit UA style rule selectors
<fantasai> TabAtkins: Who is asking for this? In the UA is one thing, but do other people need it?
<heycam> emilio, yes that is exactly the difference
<fantasai> zcorpan: reset stylesheets use it
<emilio> q+
<fantasai> zcorpan: incorrectly, usually
<fantasai> fantasai: They are copy-pasted, so they can write a proper selector
<astearns> ack emilio
<fantasai> zcorpan: but used in lots of pages, should get all the cases correct
<fremy> https://github.com/sansotmon/asistencia-salvarte/blob/50dde64556294e8e42dbb2f7950f1b9c078ebef7/web/core/themes/olivero/css/components/form-select.css
<TabAtkins> Importantly - if they're not getting it right, *is this causing problems for people*?
<fantasai> emilio: empty size attribute is another case
<fantasai> emilio: also slightly more efficient to do a pseudo-class
<fremy> ```[dir="ltr"] select[multiple] { padding-left: 9px }```
<TabAtkins> Are they getting bugs and ignoring them because parsing numbers via CSS is hard? Or are they just not getting bugs?
<fantasai> emilio: pre-parses faster than other random attributes
<fremy> ^ this is wrong, first hit on github
<fantasai> emilio: If ppl feel this is useful, then maybe it's not worth copy-pasting a weird incantation
<rachelandrew> q+
<astearns> ack rachelandrew
<fantasai> rachelandrew: I think in terms of being easier to explain and less error-prone, pseudo-class is good
<fantasai> rachelandrew: but do ppl actually want to do this, is also a valid concern
<fantasai> rachelandrew: if people aren't asking for it
<fantasai> rachelandrew: I like things to be straightforward
<fantasai> rachelandrew: but we also have a lot of pseudo-classes, and have to teach people
<fantasai> rachelandrew: so I don't have a strong feeling, but like emeyer I'm on the fence
<fantasai> astearns: Then what I want to do is to close off the discussion in this meeting, take back to issue, have whatever the actual correct integer and multiple check would be
<fantasai> astearns: so we have something to compare
<fantasai> astearns: and come back to this issue on a telecon
<fantasai> zcorpan: OK
<fantasai> astearns: any other questions on this?
<emilio> fantasai: do we want to add integer attr selectors?
<emilio> ... generally speaking, do we want a proposal for that?
<emilio> astearns: I dont' think we can decide that r/n
<fantasai> astearns: not decide right now
<fremy> select[multiple], select[size] { height: auto; }
<fremy> in bootstrap

Based on the fact we now have ::picker(select) which exists for dropdown select but not for in-page select. Could we do

select:has-picker(select) as the new selector? Question would be does this match in non-base appearance mode?

If it does match then select:not(:has-picker(select)) works for listbox. If it doesn't work then that's trickier. You'd have to do listbox styles and then potentially undo them?

I haven't read the full discussions from before but it's possible the assumptions no longer hold true.

For example if we were to change multiple to be a dropdown when in base appearance mode, in some cases you couldn't always target just based on attributes alone.

Adding this to the agenda as it would be useful to resolve on something. This is a soft blocker for base appearance listboxes.

@nt1m

@nt1m should we try and get this on the agenda for next week? It'd be handy to get a resolution on this to unblock #12468

@nt1m should we try and get this on the agenda for next week? It'd be handy to get a resolution on this to unblock #12468

Fine by me

One thing to note is that adding such a pseudo-class will effectively prevent us from adding CSS to control the listbox vs dropdown mode. That may be fine, but we need to be aware of the tradeoff we are making.

I don't think that controlling drop-down box vs list box should be controllable via css.

I think that :has-picker(select) or :select-has-picker both sound reasonable to me.

@lukewarlow

One thing that was brought up in the unminuted part of the WHATWG call last week (I think by @lukewarlow?) was that for all controls with pickers, there may be value in providing a way to render the picker inline. E.g. for date pickers this could be part of a range input control. Perhaps this could also be useful here.

To sum up my position from the call, while it seems like useful functionality, the way it is currently discussed has several warts. Using a plain :has-picker would imply that this works for other controls with pickers (date inputs, color pickers etc — those targeted by input.showPicker()), but :has-picker(select) is incredibly weird and unprecedented.

But most importantly, if :has-picker only works for appearance: base as was discussed, that introduces a circularity:

select {
	appearance: base-select;
}

select:has-picker {
	appearance: auto; /* now it no longer matches */
}

We have historically avoided making selector matching depend on CSS properties for this reason.

The CSS Working Group just discussed [selectors] Add pseudo-classes for `<select>` being a drop-down box vs a list box.

The full IRC log of that discussion

<masonf> jarhar: There is an existing pseudo class for this in Chrome, and it'd be good to make that accessible to the web.
<Lwarlow> Q+
<masonf> jarhar: This will be helpful for the next issue - defining styles for dropdown vs listbox
<masonf> jarhar: Lea brought up that this means it won't be CSS-controllable to switch between listbox and dropdown. It'd be circular.
<masonf> jarhar: I don't think it should be controllable via CSS, we should just expose the thing we already have.
<masonf> jarhar: Two alternatives I saw: a has-picker() with the element, or select:has-picker
<astearns> ack Lwarlow
<masonf> jarhar correct my naming please
<masonf> lwarlow: could just be :has-picker, because people will put the element in the selector anyway
<masonf> lwarlow: the compat problem here is different from the appearance:base problem
<lea> Yes, I think `select:has-picker(select)` looks very weird from an author pov
<lea> q?
<masonf> lwarlow: with this pseudo class, it's less important. It'd be nice to just use select:has-picker
<masonf> lwarlow: perhaps you could do this in the future via CSS, if you have a rule that applies when the element renders
<masonf> astearns: whatever method we use to switch, you're saying we could make the pseudo only apply when it renders?
<masonf> lwarlow: maybe it only switches until the element renders, and then locks in until it stops rendering, to avoid circularity.
<masonf> lwarlow: I don't like CSS for this anyway, but I'm saying this doesn't block it if we really want to in the future
<masonf> lwarlow: appearance:base doesn't allow you to switch while the picker is open
<lea> q+
<masonf> lwarlow: having the switch in HTML makes sense, the size attribute makes sense
<masonf> lwarlow: I like the :has-picker because it matches
<astearns> ack lea
<masonf> lea: I'd support making this non-functional pseudo class
<masonf> lea: seems weird to duplicate the element type
<masonf> lea: very little precedent for selectors like this. Others are quite different.
<masonf> lea: if this only works for select, we need something to not break compat. Can't it just work for all pickers?
<Lwarlow> Q+
<masonf> lea: there is already showpicker. Perhaps we can just make it work?
<astearns> ack Lwarlow
<masonf> lwarlow: showpicker is designed so that it doesn't reveal whether there's a picker
<masonf> lwarlow: it also doesn't fully work in the web. E.g. ios webkit - only works for color picker. Or something else. But not all.
<lea> q+
<masonf> lwarlow: key reason is that detecting whether the picker opened is tough. I've implemented it but can't write tests.
<masonf> lwarlow: :has-picker would have the same behavior/problem
<masonf> lwarlow: it can work for base pickers - popovers are easy. But auto appearance pickers are tough
<masonf> lwarlow: also a question about whether we want to expose that. If authors depend on needing a picker, it causes issues.
<masonf> lwarlow: but select is different because both modes are specified and expected to exist
<astearns> ack lea
<masonf> lea: stepping back, do we need a pseudo class at all?
<masonf> lea: you can detect with attributes, and this is just making it easy. Maybe defer?
<una> q+
<masonf> lea: all proposed solutions have problems. If single :has-picker, I'd expect it to work everywhere. Requiring an argument is weird. It could be :drop-down?
<masonf> lea: if it doesn't work for appearance:auto, that would also be surprising.
<astearns> +1 to concern about this only work with appearance: base
<masonf> lea: having css properties affect pseudo class matching is circular
<astearns> ack una
<Lwarlow> Q+
<masonf> una: It's a bit of an edge case to ship an entire pseudo class for this. The author knows whether there's a dropdown.
<masonf> una: let's not call it drop-down by the way
<masonf> una: we could debate the naming, but maybe let's not open that can of worms
<masonf> una: can't you do this with style queries?
<masonf> una: do we need to launch this now?
<masonf> q+
<lea> qq+
<astearns> ack lea
<Zakim> lea, you wanted to react to una
<masonf> lea: with style queries you can only target the element not the descendants
<masonf> una: author still has control
<astearns> ack Lwarlow
<lea> does it have a picker in iOS? Is that considered a picker?
<masonf> lwarlow: to clarify - a select in dropdown mode always has a picker. Problem with auto appearance isn't there.
<masonf> lwarlow: people might write styles that don't transfer - they need to know whether a picker actually opened
<masonf> lwarlow: not queryable via style queries or attributes. E.g. size attribute with invalid value.
<masonf> lwarlow: mobile browsers have a system where it's always a dropdown, even if you have size attributes, etc.
<masonf> lwarlow: also useful to apply stylesheets in specs and browser implementations
<una> q+
<masonf> masonf: why did we need it in the UA stylesheet
<masonf> jarhar: I don't think we can use style queries to do this, but I don't know for sure. Gut says no.
<astearns> ack masonf
<masonf> una: Luke was talking about mobile not respecting size attribute. Is that what we're resolving here?
<masonf> una: feels like something is unexpected with mobile browsers now, right?
<masonf> jarhar: I'm planning to make a change to make it always the same across mobile and desktop
<Lwarlow> The solution would be this selector right?
<masonf> una: this issue would be different in that case?
<masonf> q+
<astearns> ack una
<lea> q?
<masonf> jarhar: I want the pseudo class so I can define different styles
<lea> q+
<masonf> jarhar: I Don't think there are selectors that can do the same thing
<Lwarlow> Q+
<lea> q-
<astearns> ack masonf
<lea> q+
<masonf> masonf: you can't match exactly what :has-picker does with just a selector
<astearns> ack Lwarlow
<masonf> lwarlow: the other aspect other than invalid size. Even if queryable, there are a number of permutations in your stylesheet. No attributes, multiple attribute, size attribute, all permutations of those, etc.
<masonf> lwarlow: I'm not sure we need to force browsers (from a spec perspective) to do something specific for appearance:auto
<masonf> q+
<masonf> q-
<masonf> lwarlow: still value in having this pseudo in appearance:auto and base. E.g. what if you have mixed modes, base on the in-page, auto on the picker
<masonf> lwarlow: each browser already has this, let's just expose it
<astearns> ack lea
<masonf> lea: can't easily do this with style selectors, but solution isn't an ad-hoc selector
<masonf> q+
<RRSAgent> I have made the request to generate https://www.w3.org/2025/07/24-css-minutes.html fantasai
<jarhar> q?
<masonf> lea: if we add a pseudo class, it needs to match appearance:auto
<Lwarlow> But that still doesn’t solve the issue (but yes we should have that)
<masonf> lea: I put a code snippet that shows circularity if you don't support appearance:auto
<masonf> lea: you said browser doesn't know if it showed a picker
<jarhar> q+
<masonf> lea: for author code, you know what you have generally. I don't know about use cases.
<masonf> lea: frameworks and libraries can have complex selectors
<astearns> ack masonf
<jarhar> masonf: the selector is pretty complicated, so frameworks and libraries are an actual use case
<lea> q+
<jarhar> masonf: its similar to ua stylesheets, its complicated enough that every browser has done it this way
<Lwarlow> It’s not even complicated it just isn’t possible…
<jarhar> masonf: it seems like the crux of this argument is
<jarhar> astearns: id like to see evidence that each browser does this
<jarhar> masonf: i think chromium and webkit have it
<lea> s/lea: for author code, you know what you have generally. I don't know about use cases./lea: for author code, you know what you have generally. I cannot think of use cases outside CSS frameworks and libraries, which can afford to have more complex selectors./
<jarhar> masonf: the selector youre talking about is complicated or currently impossible given the parsing rules for size, the selector is giant if it can be done
<jarhar> masonf: i think this comes down to naming or can it be done for everything
<lea> s/lea: frameworks and libraries can have complex selectors/lea: so I think the motivation is too weak to justify the complexity involved/
<jarhar> q-
<jarhar> masonf: can we return to the question of making it work for everything that has a picker?
<una> +1
<jarhar> masonf: its not possible for a browser to know whether it tried to open a picker
<jarhar> masonf: this might be a corner case
<Lwarlow> Q+
<jarhar> masonf: maybe we could just do :has-picker and make it work everywhere
<astearns> ack lea
<lea> The only reason it's complicated today is that we can't just `[size > 0], [multiple]`, which doesn't seem that complicated?
<masonf> lea: wanted to reply to the complex thing today. Reason is that we can't ... see comment
<masonf> lea: can't do attribute values today, but if we could, then
<lea> q?
<astearns> ack fantasai
<masonf> fantasai: I don't think we should go down the generic :has-picker thing
<masonf> fantasai: can we do that with pseudos
<lea> (that said making `:has()`work with pseudo-elements is also a common ask)
<masonf> fantasai: we don't have a generic use case here. Select is particular in that it has two forms.
<masonf> fantasai: let's do a specific select thing, therefore
<masonf> fantasai: I can imagine styling differently if the picker is shown, but that would be :picker-shown
<astearns> ack Lwarlow
<masonf> lwarlow: big +1 to that. Selector that just works for listbox vs. dropdown then that's great.
<masonf> lwarlow: especially if we don't see this being useful for inputs. There might be cases, where inputs might or might not have a picker, but probably niche enough that we don't need it
<masonf> lwarlow: :has-picker is doable, but :open isn't
<masonf> lwarlow: timing is tough, but whether you try to open a picker isn't
<masonf> lwarlow: :has-listbox is fine. Reason behind drop-down vs list-box isn't exposed in the platform
<lea> presumably `:listbox` , not `:has-listbox`?
<masonf> lwarlow: should be listbox rather than dropdown, because dropdown is too overloaded
<masonf> +1 from the scribe for something like that also
<masonf> annevk: I think for most other controls, you could use @supports with the picker pseudo element
<masonf> annevk: with select, there are two types of controls, only one with a picker. So select is indeed special.
<lea> q+
<masonf> annevk: you can tell if it supports it, but not whether it'll show one
<masonf> annevk: we haven't designed this part yet, maybe we should wait to define the rest first?
<lea> +1
<masonf> annevk: one concern I heard with listboxes more generally, including on desktop. On macos, there's no native ... multi-select dropdowns.
<masonf> annevk: That's a problem for trying to reconcile these things
<astearns> ack lea
<lea> Just to reply to Anne, select is the only control that has both a picker and in-page mode *currently*, but down the line we could end up with more. E.g. for date pickers at least, it has been brought up that being able to render them as an in-page calendar (possibly for use in a bigger control, like a date range control) could also be useful.
<masonf> lea: for date pickers, it might be useful to render in the page.
<Lwarlow> Multiple dropdown basically is only a thing natively on iOS and android. So yeah that’s an issue
<lea> Lwarlow: What if it defaulted to appearance: base in platforms that don't support that? Since UAs have to implement that anyway
<masonf> jarhar: I thought this would be easier. I could define this in the spec based on listbox mode, and keep the internal pseudo class in the impl.

I still feel like this would be an incredibly useful addition, especially when some browsers now render different attribute Budugs in different modes. I don't personally think a CSS way to control this is desirable, and I think the picker embedded in page cases can be solved via a HTML attribute or something.

The issue of cycles does somewhat still stand. Especially (for example) if Safari has <select multiple size="1"> render one way in appearance auto and another in appearance base.

But we already have situations where appearance can change in a selector with no effect. The below would potentially even cause cycles if it did work (the checkbox would collpase to 0width and hover would no longer apply). So is this a solved problem?

Ideally this new selector (whatever we call it) would work in all appearance modes.

<input type=checkbox>
<style>
input:hover {
    appearance: none;
}
</style>

Personally I'd be fine with just a new :list-box (name TBD) selector for select specifically for now. If we did ever want to do a :has-picker in future I think that's fine and isn't necessarily even duplicative.

Navigation Menu

Repository navigation

[selectors] Add pseudo-classes for `<select>` being a drop-down box vs a list box #7422

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[selectors] Add pseudo-classes for <select> being a drop-down box vs a list box #7422

Description

Activity

zcorpan commented on Jun 30, 2022

mfreed7 commented on Jun 30, 2022

zcorpan commented on Jun 30, 2022

bradkemper commented on Jul 1, 2022

zcorpan commented on Jul 5, 2022

bradkemper commented on Jul 6, 2022

zcorpan commented on Jul 6, 2022

zcorpan commented on Jul 6, 2022

dbaron commented on Jul 6, 2022

bradkemper commented on Jul 6, 2022

bradkemper commented on Jul 6, 2022

zcorpan commented on Jul 7, 2022

zcorpan commented on Aug 8, 2022

mfreed7 commented on Aug 8, 2022

16 remaining items

css-meeting-bot commented on Sep 16, 2022

lukewarlow commented on Apr 10, 2025

lukewarlow commented on Apr 30, 2025

lukewarlow commented on Jul 16, 2025

nt1m commented on Jul 16, 2025

LeaVerou commented on Jul 17, 2025

josepharhar commented on Jul 24, 2025

LeaVerou commented on Jul 24, 2025

LeaVerou commented on Jul 24, 2025

css-meeting-bot commented on Jul 24, 2025

lukewarlow commented on Jan 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[selectors] Add pseudo-classes for `<select>` being a drop-down box vs a list box #7422