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

If adding pseudo element interfaces and integrating them with the existing event architecture is in service of allowing developers to observe interaction with Carousels & scroll markers, might I suggest we go down a path of adding new events for these. It was mentioned in the explainer, and I'd like to prod a little more at it.

I'll quote https://github.com/danielsakhapov/CSSPseudoElementDoc#41-addeventlistener-on-a-proxyhandle, specifically the "Introduce a new specific event type" section:

> * Introduce a new specific event type:
>     * **Description**: Instead of using the standard `click` event, define a new event type like `pseudoElementClick` that only fires on the `CSSPseudoElement` handle for pseudo elements. Standard `click` events would continue to target the `Element` only.
>     * **Pros:**
>         * Avoids any ambiguity or modification related to the standard `click` event dispatch.
>         * Clearly separates the interaction.
>     * **Cons:**
>         * Introduces a new event type for a very specific interaction, potentially leading to event type proliferation.
>         * Developers might intuitively try to listen for `click` first and be confused why it doesn't work directly on the pseudo-element handle without the special dispatch phase.
>         * Doesn't fully resolve the general question of how other standard events (like `mouseover`) should interact with pseudo-elements if direct listeners are desired.

I'd like to pull out a couple of threads, mostly around the cons:

> define a new event type like `pseudoElementClick`

Doesn't have to mention pseudo elements, nor clicks. We have lots of interactions that start as a click/equivalent but aren't called that (e.g. form's `submit`). It could instead be `scrollmarkermove`, for example.

> Introduces a new event type for a very specific interaction...

Okay, why is this a con? Seems like a pro for me. Event types for specific interactions are great! They're cheap to learn and easy to ignore if you don't need/use them.

> potentially leading to event type proliferation.

Sure that's a potential, but the other possibility is that it doesn't lead to proliferation. Let's for arguments sake put a number on this. Is 5 new events a proliferation? 20? The HTML spec has over 240 events. So is a 10% increase in events a proliferation? The introduction of media elements added 28 events and developers seem fine with it. I'd wager I've _never_ used some of that ~240 and probably never will, but that's okay because they don't take up any brain space in my head, and if I need to find out if it's possible to do something like "determine when the volume of a video has changed" I can consult MDN and it will tell me the `volumechange` event exists and I'm done.

In order to avoid a theoretical proliferation of events, here, we seems to be exploring proliferation of new API surface, one which every developer may need to reckon with? That seems unfortunate.

> Developers might intuitively try to listen for `click` first and be confused why it doesn't work directly on the pseudo-element handle without the special dispatch phase.

I'm not sure what this is really saying. It seems to presume that a pseudo-element interface _will_ exist, and that developers would assume that `click` would simply work? We can document and educate developers on new events. Is there something I am missing here?

> Doesn't fully resolve the general question of how other standard events (like `mouseover`) should interact with pseudo-elements if direct listeners are desired.

It seems the predicate of this con is "if direct listeners are desired". So let's suggest they're not. Is this still a con? Is it worth exploring if these listeners are desired before enumerating it as a con?

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


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

Received on Friday, 8 August 2025 11:45:18 UTC