[csswg-drafts] Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s) (#12161)

danielsakhapov has just created a new issue for https://github.com/w3c/csswg-drafts:

== Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s) ==
Full context: https://github.com/danielsakhapov/CSSPseudoElementDoc?tab=readme-ov-file#32-parameterized-pseudo-elements

Description:
How to retrieve pseudo argument(s) for e.g. `::part(foo)`, `::view-transition-group(name)`, `::slotted(selector)`? Should it just be a part of [`type`](https://www.w3.org/TR/css-pseudo-4/#dom-csspseudoelement-type) value or a new attribute e.g. `argument` should be added?

* Include parameter within the `type` attribute
    * **Pros:**
        * Requires no changes to the existing interface structure (no new attributes).
        * The complete identifier used to retrieve the pseudo element is available.
    * **Cons:**
        * Developers would need to manually parse the `type` string to separate the base pseudo element name (e.g., `::part`) from its argument (e.g., `foo`).
        * Less structured; mixes the type identifier with its arguments.
        * Could become cumbersome if future pseudo elements allow more complex argument syntax (e.g., multiple arguments, different data types).
* Add a new dedicated attribute (e.g., `argument` or `parameters`)
    * **Description**: Introduce a new nullable read-only attribute specifically for the parameter(s). This could be a single string (e.g., `argument: CSSOMString?`) or potentially a sequence if multiple parameters were ever supported (e.g., `parameters: sequence<CSSOMString>?`). For `element.pseudo('::part(foo)')`, this new attribute would return `"foo"`, while the `type` attribute would likely return just `"::part"`.
    * **Pros:**
        * Provides clean, structured access to the parameter value(s).
        * Separates the core type identifier (`type`) from its specific arguments.
        * More extensible and robust for handling potentially more complex parameterized pseudo elements in the future.
        * Easier for developers to work with, avoiding manual string parsing.
    * **Cons:**
        * Requires adding a new attribute to the `CSSPseudoElement` interface, increasing its complexity slightly.
        * Requires defining the behavior for non-parameterized pseudos (e.g., should the attribute be `null`, an empty string, or an empty sequence?).

**Recommendation:**
Add a new dedicated property. Providing direct access to the parameter via a dedicated attribute improves developer ergonomics by avoiding manual string parsing and clearly separates the pseudo element's fundamental type from its specific instance arguments, also it is somewhat future-proof.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12161 using your GitHub account


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

Received on Monday, 5 May 2025 13:07:27 UTC