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

> 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. [chrome.dev/carousel/horizontal/pages](https://chrome.dev/carousel/horizontal/pages/), [codepen.io/flackr/pen/yLmyPEV](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.

To be explicit here: I acknowledge this limitation of real elements, and I can concede that implementing a `CSSPSeudoElement` interface is _one way of solving this_. I, however, believe it is a suboptimal choice, and I think we should continue to exhaust other avenues to ensure we end up with a solution which we collectively believe to be the right choice. Therefore I am encouraging us to question whether or not new events could reasonably satisfy the underlying goals here.

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

How does `CSSPseudoElement` do this in a way which developers can understand, if not by the pseudo element name?

> Per the interface at [w3.org/TR/css-pseudo-4#CSSPseudoElement-interface](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.

This sounds like a lint rule waiting to be written, which concerns me.

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

This sounds even more confusing for a developer. How does a developer know when a pseudo element is active or not?

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

The difference that it is "one more thing" to think about, expanding the list of potential problems.

I'd perhaps make the bold assertion that delegated events vs direct event listeners are a topic that has had a lot of writing about for many many years and is something developers frequently misunderstand or misinterpret, and still ask about today. As an example from just the other week: https://github.com/whatwg/dom/issues/1396. Perhaps one could conclude from this that if we were designing elements and events today, we'd consider a design which is less confusing for developers to understand where strong references are - and perhaps we should be asking ourselves this same question today?

-- 
GitHub Notification of comment by keithamus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12163#issuecomment-3175271035 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 15:03:07 UTC