- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Oct 2025 16:03:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``How to handle addEventListener on `CSSPseudoElement`?``.
<details><summary>The full IRC log of that discussion</summary>
<sakhapov> sakhapov<br>
<masonf> sakhapov: pseudo elements and events. We always run into the CSS/HTML boundary.<br>
<masonf> ... latest proposal is not to mess up HTML, and add pseudo target property to event object. And keep firing only on originating elements (real elements).<br>
<masonf> ... pseudoTarget would just let you know where the event actually came from.<br>
<masonf> ... just add information we need to existing stuff. And some potential syntactic sugar to add listener to the pseudo, which is equiv to a listener that checks .pseudoElement.<br>
<masonf> s/pseudoElement/pseudoTarget<br>
<flackr> q+<br>
<masonf> sakhapov: special mention for boundary events: by default they should be turned off, like today. Going between pseudo and originating element, you just get one event.<br>
<masonf> ... some option to be added to get multiple boundary events.<br>
<lwarlow> q+<br>
<astearns> ack flackr<br>
<masonf> flackr: I suggest that we start simple, with just the pseudoTarget.<br>
<masonf> ... opting into boundary events changes the set of events we have to fire, which has implications.<br>
<masonf> ... just adding the pseudoTarget would handle a ton of use cases already<br>
<masonf> ... we can separately do something more complicated later.<br>
<keithamus> q+<br>
<smaug> q+<br>
<masonf> sakhapov: boundary events - the proposal is indeed not to change them now.<br>
<masonf> flackr: we might eventually make that work by generating boundary events at *all* pseudo elements, rather than an opt-in. But for now, let's just do pseudoTarget.<br>
<masonf> astearns: anne wants to know what pseudoTarget returns?<br>
<masonf> sakhapov: CSSPseudoElement already exists, and that's what you get back. element.pseudo() function, and it returns this CSSPseudoElement. Persistent proxy to the pseudo element.<br>
<masonf> annevk: does it return null when there's no pseudo element target.<br>
<masonf> sakhapov: event.pseudoTarget will be null in that case<br>
<astearns> ack lwarlow<br>
<masonf> lwarlow: two questions. How does this work with nested pseudos?<br>
<masonf> ... if I click on a ::before within ::details-contents, I'm guessing I get ::before?<br>
<masonf> ... any way to know the nesting?<br>
<masonf> sakhapov: right, target would be ::before. The CSSPseudoElement has a .parent relationship.<br>
<masonf> lwarlow: other question is whether there's a limitation on which pseudos are supported?<br>
<masonf> sakhapov: yes, currently only supports before after, scroll markers and buttons, ... and element-backed pseudo elements.<br>
<masonf> lwarlow: details-content included?<br>
<masonf> sakhapov: yes probably. Start small and don't break.<br>
<masonf> lwarlow: don't expose ::-webkit-* stuff<br>
<masonf> astearns: are we tying together what the pseudo element class implements and the .pseudoTarget property?<br>
<lwarlow> q+<br>
<masonf> ... whatever is exposed as a CSSPSeudoElement object can be put in this new property?<br>
<masonf> sakhapov: so far yes, because it's currently limited and looking pretty safe. But we need to discuss.<br>
<masonf> astearns: I'm concerned that the sets will diverge.<br>
<lwarlow> We should update that CSS spec to remove the EventTarget parent type.<br>
<lwarlow> q-<br>
<masonf> keithamus: does this work with ::part()?<br>
<astearns> ack keithamus<br>
<masonf> ... or is that not exposed? That's element backed.<br>
<masonf> sakhapov: but ::part() is a real element.<br>
<masonf> ... just before/after/etc. Static list. Already spec'd.<br>
<masonf> keithamus: does .parent get you the parent element?<br>
<masonf> sakhapov: either originating element or parent pseudo element.<br>
<masonf> keithamus: if you haven't clicked a pseudo, but you've clicked the element, you get .pseudoTarget==null, right?<br>
<masonf> sakhapov: yes.<br>
<masonf> keithamus: if you want ::details-content::before?<br>
<masonf> sakhapov: details isn't supported yet<br>
<masonf> keithamus: what about ::foo? Do I need to do extra work if I'm getting null because not supported or because wrong target.<br>
<masonf> sakhapov: if selector is incorrect (per CSS rules) return null. Or not in the supported list, return null.<br>
<annevk> q+ to ask if EventTarget inheritance is going to be removed<br>
<masonf> keithamus: if the particular browser doesn't support a particular pseudo, I can't tell why I got null.<br>
<lwarlow> `::details-content` really should be supported here unless there's a good reason not to.<br>
<masonf> ... how do I feature detect this<br>
<masonf> can't you use supports()?<br>
<masonf> keithamus: I'm concerned about detecting feature support.<br>
<masonf> sakhapov: just use supports()?<br>
<masonf> keithamus: ok<br>
<astearns> ack smaug<br>
<masonf> smaug: I wonder about the click target. Click events aren't user events, they're based on down/up events. You may get the down on a pseudo, and up on another pseudo. Common ancestor is the click target. What's the .pseudoTarget in that case?<br>
<masonf> sakhapov: if pseudo target on mousedown/up is the same, fire click with pseudo target. If different, pseudoTarget will be null.<br>
<masonf> flackr: same common ancestor determination. Even if different, but there's a common pseudo element ancestor, you'd get that pseudo back.<br>
<masonf> sakhapov: click will still be fired.<br>
<keithamus> q+<br>
<dbaron> I would expect it to work the same as "click" works for similar cases that are all elements.<br>
<masonf> smaug: yep, just wondering about pseudoTarget in that case. Maybe that works. If you release the mouse on a pseudo element, maybe you expect the click there.<br>
<masonf> flackr: that's not how we fire clicks.<br>
<masonf> smaug: but this is new.<br>
<masonf> flackr: we have an algorithm that finds the common ancestor.<br>
<masonf> dbaron: I'd expect the existing algorithm to run on the tree that includes the pseudo elements.<br>
<masonf> annevk: then we don't support selection?<br>
<masonf> flackr: selection isn't tree abiding, so I wouldn't think we'd support it.<br>
<astearns> ack annevk<br>
<Zakim> annevk, you wanted to ask if EventTarget inheritance is going to be removed<br>
<masonf> annevk: draft still has pseudo element inheriting from event target<br>
<masonf> astearns: yes, draft is old<br>
<dbaron> s/that includes the pseudo elements/as though it was all elements, and then we do whatever mapping we're deciding on here to whatever we would normally make the target/<br>
<masonf> sakhapov: what do we think about the syntactic sugar part?<br>
<masonf> annevk: that sounded pretty awful, I liked the suggestion to start smaller.<br>
<astearns> ack keithamus<br>
<masonf> keithamus: I'd agree. I'm wondering if we can have this as a string<br>
<masonf> the .parent property, right?<br>
<masonf> keithamus: seriously look at ::backdrop as part of this.<br>
<masonf> sakhapov: ok I'll take a look<br>
<flackr> getBoundingClientRect, computed style, other future extensions<br>
<masonf> lwarlow: only details-content is element backed. Scroll marker is, but after/before aren't element backed.<br>
<masonf> annevk: is the pseudo() API enshrined already? Seems strange to parse the argument with the CSS parser. Why not an enum?<br>
<masonf> sakhapov: there can be arguments, functional pseudos, etc.<br>
<masonf> annevk: ahh ok. Currently type returns one of three strings, I assume that's what can be returned?<br>
<lwarlow> q+<br>
<masonf> sakhapov: there's a separate discussion about how to return arguments.<br>
<astearns> ack lwarlow<br>
<masonf> lwarlow: is the pseudo function meant to be static?<br>
<masonf> sakhapov: not static, exists on element. It's element.pseudo().<br>
<masonf> lwarlow: there's CSS.pseudo(). For nested?<br>
<masonf> sakhapov: yes<br>
<masonf> lwarlow: I understand what keith said, might be nice to return string<br>
<masonf> sakhapov: some pseudos exist more than once on a single element<br>
<masonf> lwarlow: how would you know that here?<br>
<masonf> sakhapov: you could add an index on CSSPseudoElement, or extend it, etc.<br>
<masonf> astearns: I like having an object here, vs. a micro-syntax.<br>
<masonf> keithamus: I agree. Was just asking what it gives you, but seems like it does have stuff.<br>
<masonf> ... I don't think we should do indexing, that's what functional pseudos are for.<br>
<lwarlow> q+<br>
<masonf> sakhapov: how would it work with event handler, that just gets pseudo target back? How would you know the index?<br>
<masonf> keithamus: you'd have hit testing. You'd have ::colon(5).<br>
<masonf> sakhapov: no, as a developer<br>
<masonf> keithamus: ahh how do I get it ahead of time to compare.<br>
<masonf> sakhapov: you're handling click event, and you just get back a CSSPseudoElement. How do you tell which one was clicked?<br>
<masonf> keithamus: depends on how the arguments are serialized.<br>
<keithamus> `::column(5)`<br>
<flackr> or ::view-transition-group(name)<br>
<masonf> s/::colon/::column<br>
<masonf> (sorry)<br>
<masonf> keithamus: if there was a way to get the full string back, I could parse it and find the 5<br>
<flackr> I like the idea of having args in some form<br>
<masonf> ... would people be grabbing these objects ahead of time, or just inspect the object I get back<br>
<masonf> ... always referential equality, or just ask the pseudo element about itself?<br>
<masonf> ... worth exploring and asking developers which way looks easier<br>
<flackr> qq+<br>
<masonf> ... my hunch is that you'd just want to ask the CSSPseudoElement about itself, rather than enumerating them and comparing.<br>
<astearns> ack flackr<br>
<Zakim> flackr, you wanted to react to lwarlow<br>
<masonf> flackr: commonly you'd just interrogate the interface. But longer term idea with the object is that it might have other useful properties like getBoundingClientRect() or parent()<br>
<masonf> flackr: if you just get a string, you have to do a bunch more work.<br>
<masonf> keithamus: I don't like the string either. Just the particulars of the design. Both are valid. Independently a developer might want to get a CSSPseudoElement and getBoundingClientRect.<br>
<masonf> ... question is whether developer is likely to pre-fetch the pseudo element object.<br>
<masonf> ... otherwise, it could just be a new element each time, rather than same object.<br>
<masonf> flackr: I think it should be same object. Not hard for browser to do.<br>
<masonf> flackr: similar to animation object - same throughout the lifetime of animation.<br>
<masonf> keithamus: lifetime of the animation run. Pseudo elements last longer.<br>
<masonf> keithamus: just pointing out that it likely doesn't matter much to developers.<br>
<masonf> flackr: probably right, so it's a nice to have, if not hard.<br>
<astearns> ack lwarlow<br>
<masonf> lwarlow: if you take the ::column() example, and you know you're on index 2, how useful is that really? They're dynamic.<br>
<masonf> ... so column 2 doesn't really mean much<br>
<masonf> ... no meaning attached to column 2, e.g. which items are in that column.<br>
<masonf> astearns: if you're doing click styling on a column, then you want to know which one to style.<br>
<masonf> ... column pseudos aren't a thing yet either.<br>
<masonf> sakhapov: you could have a scroll marker, one per page, and for statistics, you want to know which one people spend time on.<br>
<masonf> lwarlow: intersection observer?<br>
<masonf> sakhapov: better without IO<br>
<masonf> flackr: analytics people like to know how far down in an article you got. Similar here, how many pages you saw<br>
<masonf> keithamus: what events would you listen to for that?<br>
<masonf> sakhapov: {missed}<br>
<masonf> flackr: click on the scroll marker is a good indication<br>
<masonf> lwarlow: could also use arrow keys<br>
<masonf> flackr: not sufficient.<br>
<masonf> lwarlow: IO gives you all of that for free.<br>
<masonf> keithamus: analytics people like more data always<br>
<masonf> ... there are novel use cases to have the index, and not hard to add, let's just add it<br>
<masonf> lwarlow: index isn't stable. If the layout changes, indices change.<br>
<masonf> keithamus: stable at the time. If you want to get "what are the current photos to be displayed" because at the time of click, things are stable.<br>
<masonf> astearns: close it off here, times up<br>
<lwarlow> More promising than before but still not fully sold personally<br>
<masonf> astearns: sound like a promising avenue, but not ready to resolve. Maybe talk about in a full CSSWG meeting.<br>
<masonf> sakhapov: I feel like we kind of agreed...?<br>
<masonf> astearns: sounds like where we're going, but not quite there yet.<br>
<masonf> astearns: discuss on the issue and talk at CSSWG.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12163#issuecomment-3361999362 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 October 2025 16:03:31 UTC