Re: [csswg-drafts] How to handle addEventListener on `CSSPseudoElement`? (#12163)

@Loirooriol sounds reasonable, but what should `event.pseudoTarget` be in that case, once we reach the handler? For now it sounds easier to handle nested `::marker` only in the event listener attached to `::marker`, even though it's nested into `::before`. If needed, author might inspect [`event.pseudoTarget.parent`](https://drafts.csswg.org/css-pseudo/#dom-csspseudoelement-parent).

@keithamus: sure, `event.pseudoTarget` can be a string instead of a `CSSPseudoElement`, that's true, but note that there is a plan to add more functionality to the `CSSPseudoElement`, such as geometry utils to e.g. `getBoundingClientRect()`. And by obtaining `CSSPseudoElement` instead of a string authors would have much more power and control.

What would be the difference in the level of burden on developers in the string vs `CSSPseudoElement` case? In both cases all the developer would most likely do is addEventListener, receive the event and check `event.target` to understand e.g. `::scroll-marker` of which specific item of the carousel has been clicked. So they won't care if it's a string or a `CSSPseudoElement` probably? And in that sense it won't make much difference in burden level on them?

But then, if they need to do something with pseudo, `CSSPseudoElement` sounds more future proof? So that you just register the event listener in both ways, but have some additional power with `CSSPseudoElement` in case you need, and if not, you don't even have to use that field, if you register listener via proposed syntactic sugar?

-- 
GitHub Notification of comment by danielsakhapov
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12163#issuecomment-3174898292 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 11 August 2025 13:40:14 UTC