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

[zcorpan]

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/

[zcorpan]

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

[mfreed7]

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.

[zcorpan]

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.

[bradkemper]

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

[zcorpan]

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

[bradkemper]

"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)

[zcorpan]

It's not necessarily multi-select, though.

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

[zcorpan]

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) {}

[dbaron]

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

[bradkemper]

@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?

[bradkemper]

I’m ambivalent about the extra dash, really.

[zcorpan]

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?

[zcorpan]

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.