Re: [csswg-drafts] Add a property to retrieve plural instances of pseudo elements with the same selector (#12162)

The CSS Working Group just discussed `Add a property to retrieve plural instances of pseudo elements with the same selector`, and agreed to the following:

* `RESOLVED: revert previous resolution (do not add .pseudoAll() for now, wait for more compelling use-cases)`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> sakhapov: last time, we resolved to add .pseudoAll() that returns a list of csspseudo objects, for plural pseudo-elements<br>
&lt;TabAtkins> sakhapov: like ::column<br>
&lt;TabAtkins> sakhapov: that raises some questions<br>
&lt;TabAtkins> sakhapov: first is notification<br>
&lt;TabAtkins> sakhapov: csspseudoelement is designed to be identity-consistent, you get the same object back if you call it twice<br>
&lt;TabAtkins> sakhapov: how should that work with a list?<br>
&lt;TabAtkins> s/notification/reification/<br>
&lt;flackr> q+<br>
&lt;TabAtkins> sakhapov: so what if you have two columns, you call pseudoAll(), then you change your layout ot have one column and call it again. Is the first column the same in both? Then you change your layout to have two again. Are these the same objects as the first call, or new?<br>
&lt;TabAtkins> sakhapov: Second, there's no way now to detect that you have new pseudo-elements, like when the column count changes. The use-case for this is usually event listeners on the pseudos.<br>
&lt;TabAtkins> sakhapov: maybe we can return a proxy list that has .addEventListener(), and it automatically fires when any of the pseudos get the event<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> sakhapov: another is Noam's idea where there's an observer that notifies you when the list changes<br>
&lt;TabAtkins> flackr: for 1, we said the pseudoElement interface is identity-consistent, but for the list depends on whether it's a live list or not. probably not relevant, I think getElementsByTaName returns fresh lists.<br>
&lt;TabAtkins> flackr: we should determine whether it's a live list or not tho<br>
&lt;TabAtkins> flackr: for this I'd love to see what the use-cases are, to know whether it better to have a live list or a snapshot<br>
&lt;TabAtkins> sakhapov: only use-case I know now is a listener on scroll marker inside of columns<br>
&lt;TabAtkins> sakhapov: so you'd want to add new listeners as your layout changes<br>
&lt;TabAtkins> flackr: for that use-case, I don't think getting the individual pseudos is a good api<br>
&lt;TabAtkins> flackr: we could do something like the group proxy you suggested, can addEVentListener once. Could add filter params to addEventListener to filter on pseudos.<br>
&lt;TabAtkins> flackr: but it would be a bad API to have to *observe* the pseudos and constantly re-add listeners<br>
&lt;TabAtkins> sakhapov: so i'm thinking adding listener on the scroller itself... maybe we don't really need pseudoAll for now<br>
&lt;TabAtkins> flackr: I think that's reasonable<br>
&lt;TabAtkins> flackr: the other... if you can listen to changes you can treat these as individual elements, like using a mutationobserver<br>
&lt;TabAtkins> flackr: but this is more complicated to get right for devs. I think we should focus on something that lets you delegate a listener for all the pseudos<br>
&lt;TabAtkins> sakhapov: what I can see now, for our use-cases, if you can't detect the changes pseudoAll() is useless. But if you have a PseudoList object that represents all the pseudos and can take a listener... then pseudoAll() isn't needed either<br>
&lt;TabAtkins> flackr: I think it's fine to defer if the use-case for pseudoAll() is just to add listeners to all the pseudos. We can just look at filters to get addEvnetListener working<br>
&lt;TabAtkins> sakhapov: and we might want GeometryUtils on the pseudos, but we can handle that later<br>
&lt;TabAtkins> astearns: sounds like reverting the previous resolution and not adding pseudoAll() for now?<br>
&lt;TabAtkins> sakhapov: yeah<br>
&lt;TabAtkins> +1<br>
&lt;TabAtkins> proposed resolution: revert previous resolution (do not add .pseudoAll() for now, wait for more compelling use-cases)<br>
&lt;TabAtkins> RESOLVED: revert previous resolution (do not add .pseudoAll() for now, wait for more compelling use-cases)<br>
&lt;TabAtkins> sakhapov: we have another issue about listeners on pseudo-elements, almost resolved on a dding .pseudoTarget<br>
&lt;TabAtkins> astearns: okay, just wanted to make sure that's tracked<br>
&lt;TabAtkins> astearns: also heard about listening to mutations for the pseudos<br>
&lt;TabAtkins> sakhapov: we have an issue about detecting existence of the pseudo<br>
&lt;TabAtkins> sakhapov: if you have something like .exists, that's a sync layout/style update<br>
&lt;TabAtkins> sakhapov: another approach is an observer that tells you what's removed/added<br>
&lt;TabAtkins> sakhapov: but that's just alt approaches to this issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12162#issuecomment-3462590768 using your GitHub account


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

Received on Wednesday, 29 October 2025 16:28:35 UTC