- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 22 Jan 2026 16:39:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Should new pseudo-elements be restricted to base appearance mode?`. <details><summary>The full IRC log of that discussion</summary> <jarhar> lwarlow: browsers have non standard pseudos and there are also standard ones. file selector button has to match nomatter what because that already exists<br> <jarhar> lwarlow: that one will be a special case<br> <jarhar> lwarlow: if you have a file input in base appearance mode, should browsers be allowed to match webkit-file-upload-button?<br> <jarhar> lwarlow: as currently implemented, they would<br> <jarhar> lwarlow: seems aliased at the parser level<br> <jarhar> lwarlow: ideally, in appearance base only standard ones should be allowed to match<br> <jarhar> q+<br> <masonf> q+<br> <astearns> ack jarhar<br> <astearns> ack masonf<br> <jarhar> jarhar: if you can implement it, then you should go for it<br> <jarhar> masonf: since base appearance is an opt in, it seems like a good time to do this<br> <jarhar> lwarlow: to the implementable aspect, it depends on how browsers have implemented pseudo matching in the first place<br> <jarhar> lwarlow: one browser has the ability to set a pseudo element as well as a legacy pseudo, and the legacy one is explicitly a separate thing. if we had some way of doing that in each browser, then you can conditionally decide<br> <keithamus> q+<br> <jarhar> lwarlow: that feels like it should be implementable<br> <jarhar> lwarlow: maybe famous last words<br> <jarhar> lwarlow: webkit has the ability to dynamically update which element in the ua shadow tree matches<br> <jarhar> lwarlow: im assuming chrome can do that as well since the actual pseudo element changes based on value for meter<br> <jarhar> lwarlow: the aliasing needs to be moved from the parser to somewhere deeper in the stack<br> <astearns> ack dbaron<br> <jarhar> dbaron: the value in getting rid of legacy stuff is about making things simpler. to some extent, its less simpler for developers since they dont need to use the legacy stuff<br> <lwarlow> q+<br> <jarhar> dbaron: some of it is also for specs and implementors<br> <jarhar> dbaron: if youre trying to get rid of legacy stuff is are you actually making things simpler or more complicated?<br> <astearns> q+<br> <jarhar> dbaron: if you get rid of legacy thing in one case but support it in another, im not sure if we actually end up in a better place<br> <jarhar> dbaron: i cant tell you for sure which way this tradeoff will go<br> <astearns> ack keithamus<br> <jarhar> keithamus: looking at customizable select right now, and its not really ideal for what selectors match based on the appearance value, and thats kind of what the ask is here<br> <jarhar> keithamus: that can be a little weird. id like to avoid it if we can<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: its tricky because i think developers can ignore it, they can just use the new stuff, except for the fact that develoeprs dont write all of their own css, and i can see a world where you will have external css which have resets which will apply to these legacy pseudos to reset things you dont want to reset if youre using appearance base<br> <jarhar> lwarlow: you could have the same issue with file selector button, but that one is less likely to be an issue because button is relatively already ok<br> <jarhar> lwarlow: i think youll probably have lots of styles that are display:none'ing random pseudos and setting appearance values<br> <jarhar> lwarlow: the flipside is that for the new pseudo elements, do we want them to match in appearance auto? probably not<br> <jarhar> lwarlow: for some trees it might be that you switch which one is visible and its not an issue<br> <jarhar> lwarlow: for color input, mozilla has moz-color-swatch, and that would match the new pseudo element, but we probably dont want the new pseudo to match in appearance auto mode. i know anne is keen in appearance auto to be up to the user agent<br> <jarhar> lwarlow: we dont want to introduce some of these new pseudos match in appearance auto and some dont<br> <jarhar> lwarlow: i think that aspect will be tricker for developers<br> <keithamus> q+<br> <jarhar> lwarlow: if you want to use new styling, you opt into appearance base<br> <jarhar> lwarlow: if you dont want to use the new stuff, then you have the tradeoff that its less stylable<br> <masonf> q+<br> <jarhar> lwarlow: my preference is dont match new stuff in appearance auto and dont match old stuff in appearance base<br> <astearns> ack astearns<br> <jarhar> astearns: i am concerned like david about the complexity of the situation for authors. im worried we might get into some cases where the legacy pseudo is applicable to the appearance base stuff, but because weve said that old pseudos cant work with the new mode, we have to mint a new pseudo that is the same as the legacy one with a different name,<br> <jarhar> which seems confusing to me<br> <astearns> ack keithamus<br> <jarhar> keithamus: looking at customizable select, and what were trying to aim for is that we will use the same shadow tree for auto and base, and it will come down to a css sheet. we might end up with an at rule, chrome has magic switcher function<br> <lwarlow> q+<br> <jarhar> keithamus: shadow tree is consistent whether youre in base or auto mode, and the pseudos are consistent<br> <jarhar> keithamus: the resulting difference is - in some cases where we paint a native widget, were going to hide parts of the shadow tree. pseudo elements will always match, but they might match a node that is display:none<br> <jarhar> keithamus: i dont know if the proposition is correct or if thats a meaningful difference or not<br> <astearns> ack masonf<br> <jarhar> masonf: i think we need to be talking about generalisms and not specifics<br> <jarhar> masonf: maybe its ok to not support the same thing on base and auto. probably shouldnt support webkit prefixed stuff in appearance base, but surely we have to take these case by case<br> <jarhar> masonf: generally i think its ok for appearance base to have different pseudos than appearance auto<br> <jarhar> masonf: theres checkmark pseudo element for select which doesnt make sense in auto since theres no checkmark in auto<br> <jarhar> masonf: i dont think generalization will just work<br> <jarhar> astearns: i dont think one by one will work. heres this legacy stuff and heres the exceptions that apply in appearance base seems fraught to me<br> <jarhar> masonf: webkit file selector button, when we get to do appearance base on the file input, were going to have to figure out what the compat situation is and what people want to do<br> <jarhar> masonf: i share your comments on davids, we should focus on the developer pov<br> <jarhar> masonf: that should be the goal, make that situation better<br> <astearns> ack lwarlow<br> <jarhar> lwarlow: i dont know how realistic it is for firefox to want to keep the thing layout whether its base or auto. maybe it has more ? than chrome<br> <jarhar> lwarlow: less of mozillas pseudos are web exposed, its possible you can rearrange them and its less of a problem<br> <jarhar> lwarlow: the color inputs structure matches appearance base and thats fine<br> <jarhar> lwarlow: for the range input, mozilllas range input might be structured differently than appearance base<br> <keithamus> q+<br> <jarhar> lwarlow: webkits range input is structured differently to mozillas, so one of them has to decide to cchange the structure, or change it for auto and take the compat hit<br> <jarhar> lwarlow: ultimately appearance auto should be up to each user agent<br> <jarhar> lwarlow: and thats annes point. if we allow these pseudos to match, it does limit what you can do as a user agent<br> <jarhar> lwarlow: when i say match - if the shadow tree has a checkmark but in appearance auto that doesn't change the styling, thats fine<br> <jarhar> lwarlow: i think the main thing is if you have checkmark as a pseudo - i dont even think thats web observable<br> <jarhar> lwarlow: .match doesn't match pseudo elements<br> <jarhar> keithamus: yeah you dont have access to the pseudo to match that query<br> <jarhar> keithamus: the contract for appearance auto is that its a black box, and you dont have access to the tree<br> <jarhar> keithamus: if you can style any part of it, its by the grace and good will of the browser, but base is well defined<br> <jarhar> keithamus: that doesnt preclude that they have the same tree<br> <jarhar> keithamus: i dont think anything that you have said is running contrary to what ive said<br> <jarhar> keithamus: about our desires at mozilla<br> <jarhar> keithamus: i wanted to ask mason or joey, for checkmark in option, thats a generated pseudo element right?<br> <jarhar> q+<br> <astearns> q+<br> <jarhar> jarhar: yes, it depends on appearnce value<br> <jarhar> keithamus: we can have aliases for pseudo elements, but they will be the same element across appearance base and appearance auto<br> <jarhar> keithamus: conceptually, appearance base and auto is a set of css changes, but not selector changes, only declarations<br> <lwarlow> q+<br> <keithamus> q-<br> <jarhar> q-<br> <jarhar> astearns: i think luke said it was ok for legacy thing to match as long as in the appearance base case it doesn't actually have any visible effect. i agree to a certain extent. there is a minor risk if at some point we decide that the appearance base tree actually does need this thing. then we have to have a separate selector that will match this<br> <jarhar> new part, or we allow the legacy thing to match the new part and might run into unexpected differences with peoples code<br> <astearns> ack lwarlow<br> <astearns> ack astearns<br> <jarhar> lwarlow: i personally dont mind if the new pseudos match appearnace auto. my take on apearance auto is that browsers do whatever they want. apple is keen on leaving appearance auto up to the browser<br> <jarhar> lwarlow: that does mean interop problems<br> <jarhar> lwarlow: the premise of leaving it up to the browser, but that might not work<br> <jarhar> lwarlow: i very much am ok with duplicating any webkit prefix pseudo for appearance base<br> <jarhar> lwarlow: in an ideal world, people would swap to appearance base for stylability and we could remove the webkit prefixes, but i know thats never going to happen<br> <jarhar> lwarlow: maybe we can remove some<br> <jarhar> astearns: so you would like the rule that legacy pseudos dont match appearnace base, and youre ok with new pseudos for appearance base case for styling that authors might expect legacy things to apply to<br> <jarhar> lwarlow: take color swatch, we have a new pseudo for that. kind of the same as webkit and moz color swatch. i think its fine that we make a new one<br> <jarhar> lwarlow: otherwise we end up with a weird case where other browsers have to implement a webkit prefix<br> <jarhar> lwarlow: if youre writing a new browser you should be able to make it not match any pseudos for appearnace auto<br> <jarhar> keithamus: theres no escaping it<br> <jarhar> keithamus: there are standardized webkit prefixed ones<br> <jarhar> lwarlow: if you wrote a new browser that didn't care about compat<br> <jarhar> astearns: this is not directly relevant<br> <jarhar> astearns: i think we do agree that the consideration should be authoring complexity. we should make it easy for authors and do what authors can learn and expect and use well, but there are some implementation difficulties in any of the routes that we might take that we will just have to deal with<br> <jarhar> fantasai: we should probably not have standardized pseudos that only work in some browsers. if they are in appearance auto, everyone should agree on them<br> <jarhar> dbaron: the one other thing about pseudo elements and browser specific ones is that i would at least hope - we have ended up in a world where there are some webkit prefixed things that other browsers have to implement for compat. despite the spelling of those names, we have to consider them as part of the web paltform like any other standardized<br> <jarhar> pseudo<br> <jarhar> dbaron: as far as other ones that are only in some browsers, maybe we still have the ability to remove some of them<br> <jarhar> dbaron: it would be nice if we agreed on which pseudos we have<br> <jarhar> dbaron: the ones that are cross browser and standardized, even with webkit, is not really - yes it makes it kind of legacy but its still part of the web and were stuck with it<br> <jarhar> astearns: to a certain extent, that is separate from the initial question that luke brought up, which is what do we do in the appearance base case about legacy pseudos<br> <jarhar> astearns: we still have to decide what were going to do with them. if we can get away with having them not apply in appearance base, we might be better placed to remove some of them<br> <jarhar> astearns: not sure if deciding on removal should influence this<br> <jarhar> lwarlow: i can try conditional pseudo element matching in chrome<br> <jarhar> lwarlow: if it matches in auto but not in base<br> <jarhar> lwarlow: both directions<br> <jarhar> lwarlow: then at least we can say that its implementable, at least in chromium, that can hel pthe discussion<br> <jarhar> keithamus: it might depend on the element. might be easy to do generated ones but not tree abiding ones<br> <jarhar> keithamus: a generated pseudo is lazily generated after a certain amount of styling. in gecko, tree abiding pseudos are part of the shadow tree, it would be a fair amount of work to swap shadow trees at any point during - especially because of style calculation<br> <jarhar> lwarlow: i think it would be an attribute on the element which dicates what its pseudo name is. i think mozilla has a similar concept<br> <jarhar> keithamus: the attributes are a developer tooling nicety, i dont know if it uses it<br> <jarhar> lwarlow: theres a method which changes how it matches<br> <jarhar> lwarlow: for webkit for input type search theres a magnifying class. if you set the result to 5 it changes which pseudo it matches<br> <jarhar> lwarlow: theres another condition where it can change again. the same element can match 3 separate pseudo elements<br> <jarhar> lwarlow: the tricky bit might be matching it up based on style rather than something else<br> <jarhar> lwarlow: appearance in chrome is calculated fairly early<br> <jarhar> lwarlow: and we do other decisions based on style, so it might be ok<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12365#issuecomment-3785406598 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 January 2026 16:39:58 UTC