- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 19 Mar 2026 16:01:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-forms-1] Should `::picker(select)` match `:popover-open`?``. <details><summary>The full IRC log of that discussion</summary> <jarhar> annevk: we discussed this many months ago, but its come up again because there are some demos and tests using this<br> <jarhar> annevk: despite there not really being agreement<br> <lwarlow> 1+<br> <lwarlow> q+<br> <jarhar> annevk: we dont think it should work because there is already an api for this, :open. it can do everything this can do. duplicate api doesnt seem great to expose. ill leave it at that<br> <jarhar> chrishtr: this issue was discussed 2 years ago at this call i believe<br> <jarhar> chrishtr: it was resolved<br> <jarhar> annevk: it was resolved not to create a parsing exception, but not resolved whether it should match or not<br> <jarhar> annevk: we would never have agreed to matching<br> <jarhar> annevk: the resolution there is clear that its about parsing<br> <jarhar> masonf: my memory was different. i agree that the resolution says parsing exception, but the discussion was about carving out things for it<br> <jarhar> ntim: i remember having reservations about matching duplicate api surface<br> <jarhar> masonf: css has all kinds of duplicate ways to do things<br> <jarhar> ntim: no reason to add more<br> <jarhar> lwarlow: the open pseudo class is already duplicative for dialog and details<br> <jarhar> masonf: first child and nth child 1 do the same thing, should we remove first child?<br> <jarhar> annevk: for dialog and details i would say that html changing the attributes was the wrong choice<br> <jarhar> annevk: first child and other things are different purposes<br> <jarhar> masonf: how so?<br> <jarhar> annevk: one is a superset of the other?<br> <jarhar> masonf: one is a strict superset of the other which is what were talking about here<br> <lwarlow> q-<br> <masonf> q+<br> <jarhar> lwarlow: because its a popover, i dont see a problem with it matching popover open. at the same time, its a pseudo, if browsers can do where it doesnt match if its this pseudo. i would go back to this is shipped, is there compat problems?<br> <jarhar> lwarlow: people generally do tend to be using the open pseudo class but not sure<br> <jarhar> ntim: that was the case until i discovered that mdn advice was to use popover-open<br> <astearns> ack dbaron<br> <jarhar> dbaron: there is existing spec text which says that this works. the definition of element backed pseudos says that it can match as a real element, and all other pseudos match as they would on that real element<br> <jarhar> dbaron: my reading of that resolution of not creating an exception means that the spec text applies<br> <jarhar> annevk: the html side is not defined because its just a div<br> <jarhar> annevk: a div element doesnt match popover open<br> <jarhar> annevk: i disagree with the pr<br> <emilio> Doesn't match != Doesn't parse fwiw<br> <jarhar> dbaron: i dont have much follow up other than thats how we interpreted the resolution, so we implemented and shipped based on that resolution<br> <astearns> ack masonf<br> <jarhar> masonf: theres a missing part of the html spec, it calls popover algorithms on it but its missing the fact that it has the popover attribute<br> <jarhar> masonf: the way it has to behave is as a popover, thats why the popover api was invented, and it needs to play nicely with other popovers<br> <jarhar> masonf: its very clear to me that it is a popover, we need to fix that in the spec, but i dont see us going a different direction<br> <lwarlow> q+<br> <jarhar> masonf: given that it is a popover, its confusing to say that it is a popover except for this special carve out. that is more confusing than just saying its a popover<br> <jarhar> masonf: thats why i think the earlier resolution was the correct one<br> <jarhar> annevk: im not sold on that. keith also raised a related thing here that the popover semantics should generally apply and not just to a single appearance, which i am sympathetic to. then its less clear what the popover is<br> <jarhar> annevk: generally we will need some lower level hooks to integrate in the various popover bits. select as a whole can participate in that, not just in its base appearance mode<br> <jarhar> masonf: but the picker only gets rendered and shows up in base appearance modes<br> <jarhar> annevk: theres behaviors around popovers, like you open one and other gets closed. you could do that for the native picker<br> <jarhar> masonf: that seems orthogonal<br> <jarhar> annevk: then its about the select element as a whole how it integrates with popover<br> <jarhar> masonf: we could go down that road, but what we shipped is that it is a popover when its appearance base<br> <jarhar> annevk: im not solved on the stylesheet and check other integration points<br> <jarhar> annevk: for the stylesheet there are conflicts<br> <jarhar> annevk: the popover styles ended up overriding the picker styles<br> <jarhar> lwarlow: thats because webkit uses a pseudo class instead of an attribute selector?<br> <jarhar> lwarlow: if its a popover and it has the popover attribute, then it has popover attribute styles?<br> <fantasai> pseudo-classes and attribute selectors have the same specificity<br> <jarhar> annevk: those need to be overriden, and the current style rules dont have specificity to do that<br> <jarhar> ntim: we tried to have ::picker(select), and that didnt override popover styles<br> <fantasai> but pseudo-elements don't have specificity iirc ...<br> <jarhar> ntim: anne added a pseudo for the picker to undo it, and thats very hacky<br> <jarhar> ntim: thats how we solved the specificity problem<br> <jarhar> astearns: you all asked for this issue to be put on the agenda. it would have been great to have some of those details in the issue<br> <jarhar> astearns: we could have hashed some of this out in the github issue<br> <dbaron> pseudo-classes and attributes have the same specificity, so this could be about what order things are in the UA stylesheet<br> <jarhar> astearns: ill take a look at the rest of the agenda items to prompt people to add to them<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: we should encourage authors to use select:open instead of popover-open because auto appearance mode might not be impelmented using a popover, but as a ua you might want to let users to set a background color on the picker when its open<br> <jarhar> lwarlow: the chromium non-mac ones you could do that<br> <jarhar> lwarlow: the other thing is to say that currently chromium uses popover for one of its selects, and you can style it in auto mode, which is maybe not desirable but maybe tangential<br> <jarhar> lwarlow: for consistency i think it makes sense to match, but for authors its probably better<br> <astearns> ack fantasai<br> <masonf> luke can you clarify the chromium thing you just mentioned?<br> <jarhar> fantasai: question to think about would be does popover open match if youre using a date picker for example? if not, hows that going to interact with future extensions to date pickers?<br> <masonf> q+<br> <jarhar> fantasai: with appearance auto, does popover open apply? if it doesnt, then what happens on an apple watch where we dont allow appearance base styled picker because it wont behave properly?<br> <jarhar> fantasai: they will get inconsistent results<br> <lwarlow> q+<br> <jarhar> fantasai: we either need to make popover open match whenever open matches, or we should make it never match and make people use open<br> <astearns> ack masonf<br> <jarhar> masonf: i agree we should encourage developers to use open, but i also think we should make popovers match popover open<br> <jarhar> masonf: date picker isnt a popover, so it shouldnt match<br> <jarhar> masonf: base select should match since it is a popover<br> <jarhar> masonf: thats the more confusing fact. if developers are wondering why it isn't matching and they have to come find this meeting, thats my objection<br> <jarhar> fantasai: its straightforward: its a pseudo, so it doesnt get what applies to an element<br> <jarhar> masonf: pseudo classes apply to pseudo elements<br> <jarhar> fantasai: ones that are markup based dont, and this one is sort of markup based<br> <jarhar> fantasai: it would be weird if it applies to some pickers but not others<br> <jarhar> fantasai: over time as we do more controls popover open might or might not work on others. if we allow it then we encourage authors to use it and then they will run into trouble<br> <jarhar> lwarlow: i dont understand the discussion about date pickers because the picker pseudo doesnt match them<br> <jarhar> masonf: what you just said applies to select, which is only a popover<br> <jarhar> lwarlow: date pickers will have it, and they will be defined to be a popover<br> <jarhar> astearns: we are out of time<br> <jarhar> zakim, end meeting<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10775#issuecomment-4091259351 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 March 2026 16:01:22 UTC