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

> Again I'll cite `<details>` as an example - if you don't provide a `<summary>` one is provided for you. There are no APIs which allow you to get to the provided `<summary>`, because it is provided in a limited capacity. To elevate it from "pseudo element" to "element" you provide it yourself, then it is target-able via the already available mechanisms (`querySelector` et al).

In the meeting, we covered how not all pseudo-elements are trivially replaced with real elements. There are many use cases where they are dynamically generated, even according to layout as in the carousel use case where you get a `::column::scroll-marker` for each page of content which depends on the layout of the box (e.g. https://chrome.dev/carousel/horizontal/pages/, https://codepen.io/flackr/pen/yLmyPEV). Developers *cannot* simply provide real elements because they don't know how many or which items are in each column.

> > 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.

A string value cannot disambiguate multiple pseudo-elements with the same owning element, e.g. which `::column`, or what is the parent pseudo-element in the case of view transition pseudo-elements.

> They will care because a string is easy to compare: `event.pseudo == '::scroll-marker'`. How would a developer do this if value is a `CSSPseudoElement` object? They'd have to learn with and interact with a newly introduced API, so the condition becomes `event.pseudo == event.target.pseudo('::scroll-marker')`. One might argue "that's not much longer" but it's a lot more complex because now I need to think a lot more about what the return value of `pseudo()` is.

Per the interface at https://www.w3.org/TR/css-pseudo-4/#CSSPseudoElement-interface you could use `event.pseudoTarget.type == '::scroll-marker'`. Your alternative approach would technically work for unique pseudo targets, but would fail if there were multiple pseudo-elements for the given type.

> As an example of the additional cognitive overload, to borrow from your example code:
> 
> function checkScrollMarker(handler) {
>  const scrollMarker = list.pseudo('::scroll-marker');
>  list.addEventListener('click', (event) => {
>   if (event.pseudoTarget === scrollMarker) {
>    // If the check passes, it calls the handler.
>    handler(event);
>   }
>  });
> }
> Have I just introduced a memory leak? If my `list` element no longer becomes a CSS carousel, presumably it'll clean up `::scroll-marker` and `list.pseudo('::scroll-marker')` now returns `null`, but I have an event bound which captures a `scrollMarker` object in scope.

`list.pseudo('::scroll-marker')` should not return null for cases where the selector can be valid even if it doesn't currently generate a pseudo-element, it will return an interface that will refer to the `::scroll-marker` for list when one exists. The *leak* that you refer to here seems is no different than any other element reference in scope, e.g. the `list` variable seems to be in scope and so would be kept alive. Again, I think the CSSPseudoElement is only keeping a strong reference to the element but the pseudoElement it refers to may or may not currently exist depending on style.

We of course still need to figure out how this would work for `::column::scroll-marker` where there are multiple pseudo-elements.

-- 
GitHub Notification of comment by flackr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12163#issuecomment-3175171832 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 14:40:51 UTC