Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s)

[danielsakhapov]

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

[emilio]

Semi-unrelated, but I don't think CSSPseudoElement should represent things like ::part and ::slotted. Those are fully element-backed...

[danielsakhapov]

Right, I must've added those just for an example afterwards, sorry.