- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 09 Apr 2026 16:01:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `What pseudo-elements should be allowed after ::picker(select) ?`. <details><summary>The full IRC log of that discussion</summary> <jarhar> annevk: we had a discussion 2 tpacs ago at least about this and how the pseudo elements should behave for form controls in general<br> <jarhar> annevk: not all of us ended up settling on how this should work<br> <jarhar> annevk: various debates on whether they should be exactly like the part pseudo-element. some could be like part, but not all of them, like picker-icon<br> <jarhar> annevk: should all the pseudo elements that we have for form controls be consistent with each other, or should there be two separate classes<br> <jarhar> dbaron: the position ive been taking here is that the things that can be element-like should be element-like<br> <emilio> +1<br> <jarhar> dbaron: for a few reasons. one is that its similar to part and that its a simillar pattern that can be applied to a lot but not all of pseudo elements<br> <jarhar> dbaron: they are structured in a way that can be backed by an element<br> <jarhar> dbaron: just like part is<br> <jarhar> dbaron: the advantage of saying that they work just like part is that we dont have to make lots of little decisions about them<br> <jarhar> dbaron: we can just say that this one can be backed by an element, it works just like part, and were done<br> <jarhar> dbaron: we dont have to have many discussion about what every little piece of everywhthing about whether it applies or not<br> <jarhar> dbaron: we can make progress on all the other aspects of building new components<br> <jarhar> annevk: i do agree with that, i just dont quite like the way that part exposes things of the shadow tree that you might not want to expose<br> <lwarlow> q+<br> <jarhar> annevk: that goes moreso for builtins<br> <jarhar> annevk: if we define element like as the element on the other side you have to pretend its a span, that would work for me<br> <jarhar> dbaron: in practice the difference is pretty small. there are some cases where an element does things that would expose some pseudo class, like popover-open<br> <jarhar> dbaron: were saying with select were saying that part of the design is that the picker pseudo element maps to an element that is actually a popover<br> <jarhar> dbaron: by saying that it is a popover, we get a bunch of behaviors that alrady exist in the platform, and we get that it matches popover open<br> <jarhar> dbaron: for some other element like pseudo, it might expose nothing, maybe another pseudo class, like maybe its a text input and that exposes some other things<br> <jarhar> dbaron: i think we want to be able to say that we are building a thing out of some other piece of platform technology<br> <lea> +1 dbaron<br> <jarhar> annevk: i agree with that, i just dont agree with exposing it at that level<br> <jarhar> masonf: why?<br> <jarhar> annevk: i think it goes against the idea of shadow trees encapsulating that information. feels weird api wise, since for html elements we have :open and then to have both :open match and then on the picker have this other thing match feels weird<br> <cwilso> ack next<br> <jarhar> lwarlow: i largely agree with the premise of what david had said. i think that theres one spanner in this. many of these pseudo elements are conditional based on the appearance. you say that a picker is always a popover. its only a popover if the select and its picker are appearance base<br> <jarhar> lwarlow: because of the way that the api is designed, you can match the picker against something<br> <jarhar> lwarlow: its not a guarantee that its a popover<br> <jarhar> lwarlow: then you end up with this situation that it matches popover open in some cases but not other<br> <jarhar> lwarlow: select:open always being the same thing as ::picker(select):popover-open isnt true<br> <jarhar> lwarlow: i think thats why it does make sense to push people to using select:open<br> <jarhar> lwarlow: i think if were okay with that kind of conditional behavior that it only happens when its appearance base then thats ok<br> <masonf> q+<br> <jarhar> lwarlow: the one that comes to mind is file selector button, that seems fine to be an element backed pseudo<br> <jarhar> lwarlow: but then youre forcing browsers to do it in appearnace auto<br> <jarhar> lwarlow: sometimes element backed or sometimes not<br> <jarhar> lwarlow: i dont know how it makes sense to do that at the css engine level<br> <jarhar> lwarlow: where placeholder is isnt defined, but for appearance:base it will be<br> <jarhar> lwarlow: we could make placeholder be an element backed pseudo, but then does that make sense since its exposing stuff<br> <jarhar> lwarlow: i do get the hesitancy<br> <cwilso> ack next<br> <jarhar> masonf: the fact that popover-open doesn't always match is a feature<br> <emilio> q+<br> <jarhar> masonf: you can style open popovers one way, and select:open another way if you want to<br> <cwilso> ack next<br> <jarhar> emilio: strong agree for everything thats been said by david<br> <jarhar> emilio: the point of these form controls is to have a good definition of what the internal tree is. exposing them as element like seems like the obvious thing to do<br> <jarhar> emilio: if were using popover then it feels weird to explicitly hide those. there are more complex cases, but for appearance:base-select stuff, the picker is a popover then why not match it<br> <jarhar> emilio: the native picker you cant style anyways, so thats not a concern<br> <jarhar> emilio: im a bit rehashing what david said<br> <lwarlow> You can style the native picker in some ways though right?<br> <lwarlow> At least in chromium<br> <keithamus> q+<br> <cwilso> ack next<br> <jarhar> keithamus: if we were to implement this using a custom element, it should match that kind of behavior, which is that it would match popover-open. if you used part if would match, and i dont know why we would be consistent with that<br> <jarhar> keithamus: unless we want to relitigate what matches after part, but i dont think thats worth reopening<br> <jarhar> keithamus: the reason were doing this is that we dont have to rely on new pseudos<br> <jarhar> annevk: i dont see it that way. theyre builtins so we get to decide what they match and what the api is. for custom elements, authors should have the ability to decide whether these end up matching<br> <jarhar> annevk: maybe your part implements the popover protocol but doesnt expose the pseudo<br> <jarhar> keithamus: i think if you were to do that then you would just wrap it in a div, or the part that is exposed not the popover<br> <jarhar> annevk: i would be happy if we specified customizable select that way, but i dont think that would work actually<br> <jarhar> keithamus: you could put the div inside of the popover, and that would be the exposed part<br> <jarhar> annevk: would that work with backdrop?<br> <jarhar> keithamus: no, but thats the concession that youre making<br> <jarhar> keithamus: unless you could target backdrop with some special magic to retarget backdrop on select<br> <cwilso> ack next<br> <emilio> q+<br> <jarhar> fantasai: one of the reasons that we went with using a bunch of custom pseudo elements per form control was partly to emphasize these are builtins<br> <jarhar> fantasai: core part of the form controls<br> <jarhar> fantasai: to be able to give them more ergonomic naming and syntax<br> <jarhar> fantasai: but also with the idea that some parts of these form controls typicall would be implemented with shadowdom but not necessarily and could be internal to the engine<br> <jarhar> fantasai: select is a bit weird because teh contents of the picker are in the page, and that makes it different from other pseudos in appearance base<br> <jarhar> fantasai: i think that was the idea of having these specialized pseudo elements<br> <cwilso> ack next<br> <jarhar> lwarlow: two things: making customizable select picker not the popover doesnt work because then that breaks transitions and various things like that because you need to target the top layer element<br> <jarhar> lwarlow: on the custom element side of things, you mentioned that custom element authors might not want to expose popover-open. ive spoken to quite a few of them and none of them have given that view<br> <jarhar> lwarlow: doesnt mean they dont exist<br> <jarhar> lwarlow: you did mention backdrop? how is that different than popover-open? you coudlnt do that with just defining these as being a span element<br> <jarhar> annevk: ideally backdrop would have been on the select element, but that might be hard to change<br> <jarhar> emilio: its different for a select to be fullscreen than for its picker to be open<br> <jarhar> annevk: youre right, it makes sense on the picker<br> <jarhar> annevk: i agree that it does expose a slight thing, but that doesnt expose anything necessarily. it feels a bit different. the top layer semantic<br> <cwilso> ack n<br> <jarhar> annevk: its also part of css<br> <cwilso> ack next<br> <jarhar> emilio: i was on the side of using part for this all along. i think we should just default to the element like behavior if we think it can be<br> <jarhar> emilio: it does expose more things<br> <jarhar> emilio: there are some things like attr that behaves funkily with part, and maybe we should fix those<br> <jarhar> emilio: but in general i think theres a lot of useful stuff that css exposes for regular elements<br> <jarhar> emilio: like before, add something else<br> <jarhar> emilio: those are useful. you can imagine having a before on a picker to have an arrow or something<br> <jarhar> emilio: basically if the way these are defined is that these are real elements, i dont see the point of litigating every pseudo that can go after it. 90% of them are useful. some of them expose that its a popover, but i dont get why not exposing it<br> <jarhar> annevk: we dont have to litigate every pseudo, but we can say that its just like a span<br> <cwilso> q+<br> <lwarlow> q+<br> <jarhar> emilio: then youre making up a new concept. you still want all the popover like thing<br> <jarhar> emilio: i dont understand dying on this hill<br> <jarhar> dbaron: if you say it acts like a span, then you break a whole bunch of behaviors, like open close behaviors, backdrop, and a whole bunch of other things<br> <jarhar> dbaron: the platform gives us solutions for this things. and it gives us a really simple thing for -<br> <jarhar> annevk: open close animations are borked<br> <lwarlow> q-<br> <jarhar> emilio: i agree but thats tangential<br> <jarhar> cwilso: maybe we should take the same approach and have a straw poll since we dont seem to be converging<br> <cwilso> ack f<br> <jarhar> fantasai: i didnt quite understand the point about open close animation and transitions being broken<br> <cwilso> 0<br> <cwilso> s/0//<br> <jarhar> dbaron: when you have open close animations, how you defer the change to display and top layer-ness. you want the thing to be in the top layer for the entire duration for the animation, and you want it to be displayed<br> <ntim> what is the straw poll?<br> <emilio> It's about what selectors keep matching after closing<br> <emilio> And whether those break positioning<br> <dbaron> jarhar: in order to make a popover do a top layer animation, you need ...: allow-discrete, and then you to transition opacity, etc.<br> <jarhar> dbaron: anne was suggesting making the target not be the popover<br> <jarhar> annevk: i wasnt saying that, i was just saying for the purpose of what pseudos apply<br> <jarhar> fantasai: we encapsulate the fact that this is a popover to selectors. you cant select attributes of the element that is being selected here that are specific to it<br> <lwarlow> q+<br> <jarhar> fantasai: you can select the element to which picker corresponds, but you cant target things about it, like states or attributes that the element has<br> <cwilso> q- later<br> <jarhar> fantasai: but youd be able to select based on qualities of other types of elements, like hover and state classes would still work<br> <jarhar> fantasai: just like we encapsulate the sibling index, like nth child on ::part<br> <masonf> Other than ::backdrop<br> <jarhar> fantasai: similarly ::picker would hide element specific attributes of whatever element is backing it<br> <emilio> q+<br> <cwilso> ack next<br> <cwilso> q- later<br> <jarhar> lwarlow: if we encapsulate to that level then you encapsulate how the layout of the element behaves. button has layout behavior that a span doesnt. would we want to change that? i think thats web observable<br> <jarhar> fantasai: to the extent that there are attributes applied to it. not trying to encapsulate how its styled, just the information thats in the dom node and specific to it being a popover<br> <dbaron> Possible straw poll: (1) ::picker(select) exposes the same pseudo-elements and pseudo-classes that it would if it were a ::part() referencing an element that it is (for appearance base) a popover or (2) ::picker(select) does not expose pseudo-elements or pseudo-classes but the properties specified on it still apply (for appearance base) to the underlying popover element<br> <jarhar> fantasai: file-selector-button has a lyout. if we define these to be spans<br> <jarhar> ^ was lwarlow<br> <cwilso> ack next<br> <jarhar> i missed some stuff<br> <lwarlow> Maybe its input button that's more limited I guess<br> <jarhar> emilio: the practical impllications of the pikcer being a popover is that it wouldnt match popover-open, and it feels like an odd special case. you want to match backdrop so you want to make an exception for that. we should just define what the element is and what it does and live with the consequences<br> <jarhar> emilio: the fact that a picker can match popover open maybe is a bit weird since it exposes the information twice, but honestly thats fine<br> <cwilso> Straw poll: (1) ::picker(select) exposes the same pseudo-elements and pseudo-classes that it would if it were a ::part() referencing an element that it is (for appearance base) a popover or (2) ::picker(select) does not expose pseudo-elements or pseudo-classes but the properties specified on it still apply (for appearance base) to the underlying popover element<br> <masonf> 1<br> <fantasai> I think (2) is more ::picker(select) only exposes pseudo-elements or pseudo-classes that apply if the backing element were a basic <span><br> <lwarlow> I still think it could be funky between appearance modes but, 1<br> <keithamus> 1<br> <jarhar> 1<br> <fantasai> 2<br> <emilio> 1<br> <keithamus> (Annevk: 2)<br> <ntim> 2<br> <castastrophe> abstain<br> <dbaron> (replacing (2) with fantasai's description)<br> <dbaron> 1<br> <astearns> 1<br> <lea> 1<br> <cwilso> 7 for 1, 3 for 2<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/13590#issuecomment-4215651315 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 April 2026 16:01:56 UTC