Add a property to retrieve plural instances of pseudo elements with the same selector

[danielsakhapov]

Full context: https://github.com/danielsakhapov/CSSPseudoElementDoc?tab=readme-ov-file#33-plurality-multiple-pseudo-elements-of-the-same-kind

Description:
For pseudo elements like ::view-transition-old(*) / ::view-transition-new(*) (where * could match multiple captured elements with the same tag name), ::column pseudos and each can have distinct ::scroll-marker inside, how to retrieve all pseudos via Element.pseudo(type) which implies a single object per type?

• Element.pseudo(type) returns the first or a representative one.
  • Pros: Simple, fits the current IDL.
  • Cons: Incomplete, doesn't allow access to other instances.
• Introduce Element.pseudos(type) returning a NodeList-like collection (CSSPseudoElementList?).
  • Pros: Explicitly handles plurality. Aligns with DOM patterns like querySelectorAll.
  • Cons: Adds new API. How would items in the list be uniquely identified or ordered if they are not tree-abiding?
• Parameterize potentially ambiguous pseudos, and let the parameter distinguish them (e.g. make ::column(selector)).
  • Pros: Uses an existing mechanism for some cases.
  • Cons: Not a general solution.

Recommendation:
We likely need an Element.pseudos(type) or a similar mechanism for pseudo elements that are inherently plural, as it's been requested by authors to e.g. add a click event listener to gather clicks statistics from every ::scroll-marker nested into ::column.

[flackr]

Cons: Adds new API. How would items in the list be uniquely identified or ordered if they are not tree-abiding?

We already have to define ordering between pseudo-elements for composition order in web animations (reflected in getAnimations({subtree: true }); https://www.w3.org/TR/web-animations-1/#dom-documentorshadowroot-getanimations

I think we should use the same ordering here.

[css-meeting-bot]

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: add element.pseudoAll that returns a list of CSSPseudoElement

The full IRC log of that discussion

<kbabbitt> flackr: proposal is to extend what we have in CSS pseudo to allow retrieving the pseudo elements that have multiple instances
<kbabbitt> ... if a browser does implement CSS pseudos, this is probably a good thing to do because we have many pseudos that can be matched with generic selectors
<kbabbitt> ... I agree with the proposal that it should behave a lot like querySelectorAll
<Rossen4> q?
<Rossen4> ack lwarlow
<kbabbitt> TabAtkins: also agree with use case and proposed ordering behavior flackr suggested in the issue
<kbabbitt> seems reasonable to me as well
<kbabbitt> fantasai: 3 different proposals, which one?
<kbabbitt> flackr: element.pseudo is already in the css-pseudo-4 spec
<kbabbitt> ... proposal would be to add a method that gets all pseudos
<kbabbitt> ... first one I believe, something qSA-like
<kbabbitt> ... that returns all matching pseudos
<kbabbitt> TabAtkins: yes, the one listed under the Recommendation heading
<kbabbitt> flackr: open to bikeshedding
<kbabbitt> fantasai: okay with this
<kbabbitt> ... for element.pseudo would that return first?
<kbabbitt> flackr: yes
<kbabbitt> TabAtkins: yes, same as qS vs qSA
<kbabbitt> ... for bikeshedding purposes we should make it pseudoAll? not most grammatical but parallel naming is important
<kbabbitt> Rossen4: actualy it's not bad
<ydaniv> +1
<kbabbitt> flackr: seems reasonable
<JakeA> Also things like `matchAll` exist
<TabAtkins> true!
<kbabbitt> Rossen4: any other suggestions?
<kbabbitt> Rossen4: Proposal is to add element.pseudoAll that returns a list of nodes
<kbabbitt> Rossen4: objections?
<JakeA> List of `CSSPseudoElement`
<kbabbitt> flackr: yes, not list of nodes, list of CSSPseudoElement
<kbabbitt> RESOLVED: add element.pseudoAll that returns a list of CSSPseudoElement
<Rossen4> ack ntim
<kbabbitt> ntim: I think element.pseudo was resolved on different issue
<kbabbitt> Rossen4: if you feel we need to discuss more, bring up that other issue or open a new one
<flackr> +1 we'll keep the names in sync

[danielsakhapov]

I've missed the discussion unfortunately, but I think we should discuss this one more time.

I have concerns such as: .pseudo() returns a persistent-identity proxy to pseudo element, pseudoAll returns a list that is layout dependent. We should specify then things like - should we do synchronous style and layout update when an author does .pseudoAll()? How should e.g. addEventListener behave if a list gets new items? Probably a few other questions as well.

[tabatkins]

flush style/layout?

Yes, I presume so, same as calling gBCR()

How should e.g. addEventListener behave if a list gets new items?

Oh, I presumed the list was just a dumb list and you were getting PseudoElement objects, so you'd just call aEL() on each of them. Are you envisioning something different?

[danielsakhapov]

I was thinking about handling newly added e.g. ::columns. There is no straightforward way to determine this, so what if we returned not a dumb list, but rather a persistent-identity CSSPseudoElementArray, which would eliminate the need for synchronous style/layout (so act like a proxy the way CSSPseudoElement does). And then you could do addEL() on that CSSPseudoElementArray which would be equal to having addEL() on all existing and future CSSPseudoElement items of that list?
And if you need individual items for whatever reason you can have CSSPseudoElementArray.items?