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