- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 09:47:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-pseudo-4] Proxying pseudo-elements as "real" (`<slot>`) elements``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: this is from a proposal for how to deal with pseudo elements<br> <TabAtkins> noamr: we're getting a lot more pseudo-elements added by VT, carousel, etc<br> <TabAtkins> noamr: plus older ones like before/after<br> <TabAtkins> noamr: lot of requests of how to get event listeners for them, getBoundingClientRect, etc<br> <TabAtkins> noamr: usually things related to layout and rendering. UI events, like clicks or pointer events<br> <TabAtkins> noamr: so an issue is, is this a bit more than style, or a little less than dom?<br> <TabAtkins> noamr: I think usually the former<br> <TabAtkins> noamr: discussed in whatwg, lot of objection to adding more DOM-ish thing (like addeventlistener) to things that aren't in the dom<br> <TabAtkins> noamr: my proposal then is a bit different, entirely in css<br> <TabAtkins> noamr: proposal is we add actual DOM elements that can represent one or more pseudo elements<br> <TabAtkins> noamr: the original proposal was to use <slot>, but has evolved a bit<br> <TabAtkins> noamr: do `display: pseudo-element`; it makes the element a layout/event proxy for the pseudo<br> <TabAtkins> noamr: it's regular dom, you can add event listeners, aria, popovertarget, etc<br> <TabAtkins> noamr: but everything to do with layout/rendering/etc is still normal css, per the pseudo-elmeent's definition<br> <futhark> q+<br> <TabAtkins> noamr: this is slightly radical, not sure if I've explained all the tidbits<br> <TabAtkins> noamr: thinking of this as a display value because it's not actually displayed at all<br> <TabAtkins> noamr: no layout, no rendering, similar to dipslay:none<br> <astearns> ack futhark<br> <lea> q+<br> <fantasai> s/Topic/Subtopic<br> <TabAtkins> futhark: what about like :nth-child() and such? should be skipped by selectors?<br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai<br> <TabAtkins> noamr: it's part of the dom, so yes, selectors will see it. but you can't add any meaningful styles for it<br> <TabAtkins> noamr: it's effectively display:none<br> <fantasai> i/Subtopic: [css-conditional-5] Clarify/Topic: Conditional Rules<br> <TabAtkins> noamr: as neutral as possible for DOM and related stuff<br> <astearns> ack lea<br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai<br> <TabAtkins> lea: I quite like the idea. like that this is really a dom element<br> <TabAtkins> lea: also ahs potential for another pain point. pseudos can't currnetly be exposed by a web component<br> <fantasai> i/Subtopic: [css-pseudo/Topic: Pseudo-selectors/<br> <TabAtkins> lea: you can expose elements as a part, but not pseudo-elements<br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai<br> <TabAtkins> lea: maybe there's some synergy there<br> <TabAtkins> lea: you can expose a <slot> as a ::part, after all<br> <TabAtkins> noamr: correct, it's a regular element, bu tit's not rendered<br> <astearns> q+<br> <TabAtkins> TabAtkins: That means Lea's request wouldn't work, the element isn't meaningfully styleable.<br> <TabAtkins> noamr: ah right, you can't style it from outside<br> <TabAtkins> astearns: for your use-case of a component using a native element and wanting to expose its pseudos, where would you put this new element backing for it?<br> <TabAtkins> lea: you usually have it in your shadow dom already...<br> <TabAtkins> lea: another complication. this assumes you can nest the slots inside the element, but not all elements take contents<br> <astearns> ack astearns<br> <TabAtkins> TabAtkins: yeah, like a pseudo from an input?<br> <lea> s/lea: you usually have it in your shadow dom already.../lea: you have it in your shadow dom already — if it's nested within another component, you'd use `exportparts`/<br> <TabAtkins> noamr: Possibly could use <pseudo for="">, so it doesn't need to be a direct child of the element it's targeting<br> <TabAtkins> noamr: we could perhaps start with tree-abiding, though, and then have some semantic for cross-referencing<br> <TabAtkins> noamr: But the main initial use-case is for things like carousel buttons or VT before/after, things that are content-ful<br> <TabAtkins> noamr: but there's space to make it all work with some extnesions, i'd say<br> <sakhapov> q+<br> <lea> q+<br> <noamr> q+<br> <TabAtkins> astearns: anyone else ahve reservations about requiring users to chang emarkup to get this added functionality on pseudos? a little weird that css wants to add event listenres to its own pseudos, and to do that you ahve to go outside of css<br> <lea> q-<br> <astearns> ack sakhapov<br> <TabAtkins> sakhapov: the alternative was CSSPseudoElement in JS, and we discussed the issue of existence<br> <TabAtkins> sakhapov: we decided the CSSPsuedoElement was a persistent handle even if the pseudo didn't exist at the time<br> <TabAtkins> noamr: I don't see it as CSS wanting to add something, the web platform needs something between DOM and CSS<br> <TabAtkins> noamr: pseudo-elements are in the middle there, and can fall behind the chairs<br> <TabAtkins> noamr: philosophical question of what's DOM and what's CSS is blurry<br> <TabAtkins> noamr: But this is really close to a DOM thing - bubbling event listernes, direct DOM access... everything becomes pretty DOM-ish rather than a style thing<br> <TabAtkins> noamr: So I don't see this as a problem, I see it as a feature, it's actually in the DOM<br> <astearns> agreed that event listeners are DOMmish :)<br> <TabAtkins> noamr: so the css feature is just to dipslay it like it's styled by th enormal css feature<br> <TabAtkins> noamr: about the reflection thing, I think we can add things to cssom that lets you query info about the pseudo-element<br> <TabAtkins> noamr: that can be the CSSPseudoElement API, reflecting about this connection<br> <fantasai> TabAtkins: Because the pseudo-element doesn't actually do anything stylistically, its presence in the DOM doens't result in anything happening, whether pseudo exists is a CSS question, I'm ok with it<br> <fantasai> TabAtkins: I would be uncomfortable if markup was necessary to create the pseudo<br> <fantasai> TabAtkins: but since a proxy, it's fine<br> <fantasai> TabAtkins: They'll work if they need to, won't work if they don't need to<br> <sakhapov> q+<br> <andruud> q+<br> <noamr> q-<br> <fantasai> TabAtkins: should be flexible wrt CSS, so happy with how this looks<br> <astearns> ack sakhapov<br> <TabAtkins> sakhapov: one point, in carousel we have ::column pseudo which isn't really representable in DOM, and in there you can have ::scroll-marker. the number of these is layout-dependent, so you can't know in advance how many <pseudo>s you'll need.<br> <TabAtkins> sakhapov: not sure how that's addressable<br> <TabAtkins> noamr: I talked to that point a little bit. the proxy element can represeent one or more pseudo-elements<br> <TabAtkins> noamr: so if you have multiple scroll-buttons, etc, the proxy is a proxy for all the pseudo-elements with that name<br> <TabAtkins> noamr: in terms of events, there are a few things we'll have to figure out, like gBCR()<br> <TabAtkins> noamr: but I think some of those internall css reflection mechanisms... "this element supports ten pseudo-elements", we can start with the idea that <pseudo> represents 0-N pseudos<br> <TabAtkins> sakhapov: and with this approach you'll lose the ability to identify which marker, specifically, was clicked<br> <TabAtkins> noamr: I think we'll have to take some of the things from the addEventListnere proposal<br> <TabAtkins> noamr: a lot fo the concerns whatwg had with it will be gone. we have a proper element now that can bubble, etc. and then we can add info to the event about what the exact pseudo it's for<br> <TabAtkins> noamr: so we can have JS reflection about it to solve that<br> <TabAtkins> noamr: but those are details we'll need to discuss, it's not set yet. but i think ther'es a trajectory to solving it<br> <astearns> q?<br> <astearns> ack andruud<br> <TabAtkins> andruud: tab, you argued we'd be okay with it because the pseudos don't do anythign stylistically<br> <TabAtkins> andruud: but this'll change you sibling index. is that okay?<br> <TabAtkins> andruud: should we really not doing special about that?<br> <lea> q+<br> <kizu> q+<br> <TabAtkins> TabAtkins: [missed, but re-explaining why they thin kthis is fine]<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> andruud: sibling-index() would still just give changed results, tho<br> <astearns> ack lea<br> <TabAtkins> TabAtkins: yeah, it would jsut need to get worked around<br> <andruud> ^ sibling-count()<br> <TabAtkins> lea: I do think not being able to nest them into some elements would be a blocker, don't wnat to invent something new for <input> or <img><br> <TabAtkins> lea: not as much of a blocker, i think it would be desirable to expose pseudos with this mechanism for shadows<br> <TabAtkins> TabAtkins: I have a proposal in an issue for allowing pseudos in exportparts="", fwiw<br> <TabAtkins> lea: ah, let's look at that then. but still the first point<br> <astearns> ack kizu<br> <TabAtkins> noamr: point taken, we can make sure it's addressed in the proposal<br> <TabAtkins> kizu: two things, maybe long shot<br> <lea> noamr: I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D<br> <lea> s/noamr: I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D /noamr, I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D /<br> <emilio> scribe+<br> <fantasai> scribe- lea<br> <emilio> kizu: would be nice to allow inline styles<br> <emilio> ... so that they could be proxied to the pseudo-elements<br> <emilio> ... we probably don't want to allow any content inside, and as an author I'd expect content to work<br> <emilio> q+<br> <emilio> ... this could fix some of the potential a11y issues with pseudos<br> <emilio> ... so anything that can translate the dom could translate it<br> <emilio> ... so this could be some sort of templating solution<br> <emilio> ... so you could put inline svg inside the button's before slot<br> <fantasai> astearns: I think we can take this back to the issue<br> <fantasai> astearns: roman just introduced an entirely new idea<br> <fantasai> emilio: if you do ::before, the 'content' property would create the content inside that element<br> <fantasai> emilio: that's why you don't want to mess with it<br> <fantasai> astearns: it's an interesting idea, we should explore more, but no more time to day<br> <fantasai> astearns: Noam, let's take this back to the issue<br> <fantasai> astearns: you'll also need to take this to WHATNOT<br> <fantasai> noamr: not introducing a new alement<br> <fantasai> noamr: let's take back to issue with minutes<br> <TabAtkins> (I think we do need a new element, we can discuss in the issue.)<br> <fantasai> noamr: seems fairly positive in the room<br> <fantasai> astearns: I am cautiously positive. :) Seems like an interesting idea but also very scary<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12575#issuecomment-3205249798 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 09:47:25 UTC