[css-pseudo] 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.

[fantasai]

I think splitting the arguments from the type is better, though we may want to offer the composed version as well.

Note that for elements the "type" selector doesn't include e.g. the class names or IDs, so I think leaving the parameters out is conceptually consistent.

[css-meeting-bot]

The CSS Working Group just discussed Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s).

The full IRC log of that discussion

<TabAtkins> sakhapov: some pseudo-elements can ahve an argument, should we return name and arguments as one string, or separately?
<TabAtkins> sakhapov: right now CSSPseudoElement.type returns the name
<TabAtkins> sakhapov: I think it makes sense to have arguments separately, so authors don't have to parse a string
<flackr> q+
<astearns> ack flackr
<TabAtkins> sakhapov: haven't thought too much about use-cases yet, but as a future proofing
<TabAtkins> flackr: there's something nice about .type, or some property, returning the thing you passed in. so maybe .type still returns what you passed in, and we have .name/.arguments as new
<TabAtkins> sakhapov: do you think name/arguments/name+arguments is too much?
<TabAtkins> flackr: dont' think it's too much
<astearns> ack fantasai
<TabAtkins> astearns: if you have them separatley you can reconstruct the combined
<TabAtkins> fantasai: i think splitting them out is good, it makes it easy to identify classes of pseudos. matches elements too, the tagname and attributes are separate
<flackr> qq+
<TabAtkins> fantasai: so i can see wanting back what you passed, note that what you get back out will probably be reserialized in a normalized form anyway
<astearns> ack flackr
<Zakim> flackr, you wanted to react to fantasai
<TabAtkins> flackr: i do think normalization is good, but i'd like to be able to pass the string into the .pseudo() method and get back the same thing
<TabAtkins> flackr: also concerned about complex pseudos, like in VT there's a whole tree. don't have anywhere to represent that if you just have a "view-transition-image()" pseudo
<TabAtkins> astearns: running close on time, hearing agreement that arguments should be separate at least. suggesting resolving on a spearate property, details TBD?
<TabAtkins> sakhapov: we can also wait for use-cases
<fantasai> s/so i can see/but i can also see/
<TabAtkins> astearns: so could leave as-is, with the *intent* to add a separat eproperty if needed
<TabAtkins> astearns: so let's do that.
<TabAtkins> flackr: also not against renaming .type
<TabAtkins> flackr: but i do think we should have *something* that returns the full string
<astearns> ack fantasai
<TabAtkins> fantasai: i agree that makes sense, but do think .type should be the "type" of the pseudo-element, not its full arguments
<TabAtkins> fantasai: so my suggestion is .type doesn't return the params, we add another attribute that gets you the whole thing
<TabAtkins> astearns: we're out of time, take back to the issue

[danielsakhapov]

It seems like we need to come up with the names for each of the properties discussed, I suggest:

• leaving .type only for the type of pseudo-element ("::after", "::scroll-button");
• new .arguments/.parameters to retrieve the list of params (sequence<CSSOMString>["left"] for ::scroll-button(left) or null for ::after). Plural form to make it future-proof;
• new .selectorText/.identifier for the full, normalized string used to select the pseudo-element ("::after" and "::scroll-button(left)"). This should round-trip (but would that require serializing e.g. scroll-button's direction as logical?).

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to retrieve pseudo argument(s), and agreed to the following:

• RESOLVED: Add selectorText to the pseudo object

The full IRC log of that discussion

<sakhapov> sakhapov
<ydaniv> sakhapov: some context, we have pseudo interface for proxy for pseudo elements
<ydaniv> ... this object always exists
<ydaniv> ... it's just a proxy element, not a real one, even if you don't render anything
<ydaniv> ... when you pass in a selector, can have args, question is how define properties to get the args of the pseudo element
<ydaniv> ... in the last comment on the issue I have a suggestion
<ydaniv> ... we do .arguments to return a list of args, or just null if none
<TabAtkins> q+
<emilio> q+
<ydaniv> ... so that this returns a normalized text and can round-trip
<ydaniv> ... maybe someone has objection to naming?
<astearns> ack TabAtkins
<ydaniv> TabAtkins: I think these are all good, good design, this should be a sequence OM string
<ydaniv> ... I'll help to fix
<astearns> ack emilio
<TabAtkins> s/should be/can't be/
<ydaniv> emilio: this makes sense but, don't think we should call this an identifier, it's not that, don't have a better idea
<ydaniv> ... don't have on arguments vs. parameters
<ydaniv> ... do we have a precedent for that?
<ydaniv> TabAtkins: don't know
<ydaniv> emilio: so could be either way
<ydaniv> TabAtkins: I don't know what we do in CSS
<ntim> css-highlights/css-pseudo/css-view-transitions probably have examples
<ydaniv> emilio: bikesheding aside, selector text identfier aside, looks good
<kbabbitt> ::highlight uses "argument" as well
<ydaniv> astearns: what do we use for selector for a rule in CSSOM?
<ydaniv> emilio: selector text, might be a better name
<ydaniv> sakhapov: question about scroll buttons, whether should be logical or physical
<ydaniv> emilio: separate issue
<ydaniv> ... I don't know if those things alias eachother, probably discuss separately
<ydaniv> astearns: I hear we're agreeing on a typed argument selector text and separate issue for scroll buttons?
<astearns> s/typed argument selector text/type, arguments, selectorText/
<ydaniv> emilio: if you called .pseudo and pass a selector that could select multiple things should not be allowed
<ydaniv> ... the point of these are to get specific elements, so should probably just throw
<ydaniv> ... for the logical vs. physical it's a bit tricky
<ydaniv> sakhapov: we can discuss separately
<astearns> Proposed resolution: use type, arguments, selectorText
<ydaniv> emilio: arguments seems fine
<ydaniv> astearns: kbabbitt said there is precedent
<ydaniv> astearns: objections?
<ydaniv> sakhapov: for the pseudos only one argument still return a list
<fantasai> "Parameters refer to the variables listed in a function's declaration, defining the input that the function can accept. Arguments, however, are the actual values passed to the function when it is called, filling the parameters during execution."
<ydaniv> TabAtkins: currently all have one
<ydaniv> ntim: if we have ones without args,
<ydaniv> ... I think it's a bad pattern to have multiple args but to point to one thing
<ydaniv> emilio: imagine we had a pseudo element for corners
<ydaniv> [cross talk]
<ydaniv> TabAtkins: arguments is a good name for this sort of thing, we will in the future have an element with multiple args
<JakeA> q+
<ydaniv> fantasai: I think we have it just return a string
<ydaniv> TabAtkins: I rather deal with that legacy later
<TabAtkins> s/I rather/I don't want to have to/
<ydaniv> florian: we've done this before and not fun
<JakeA> q-
<ydaniv> TabAtkins: in CSS all concepts that deal with multiple args have comma separation
<ydaniv> ntim: I can see in the future using commas and still only point to one thing
<ydaniv> TabAtkins: don't see how these concepts are related
<ydaniv> ... you can have multiple and none args
<ydaniv> fantasai: it's not the parameters to a function, they just look like it
<ydaniv> ... we're creating an unneccary API here
<ydaniv> ntim: I can see this list becoming an identifier
<ydaniv> [cross talk]
<ydaniv> astearns: I think we're having difficulyt with hypothetical future stuff here
<ydaniv> ... we could go with argument for now to return a string, and in future if we have multiple we have arguments for return an array
<ydaniv> TabAtkins: sounds good!
<TabAtkins> s/sounds good/sounds bad, I hate it
<fantasai> +1 to astearns :)
<ntim> ydaniv: s/I can see this list becoming an identifier/we could name it "identifier" instead of "argument"
<florian> q?
<florian> q+
<ydaniv> florian: was thinking this example is more convincing
<ydaniv> fantasai: question is do we use commas or spaces, and how does that appear on the IDL
<TabAtkins> JS doesn't offer `.argument` and `.arguments`, with the former letting you avoid writing `[0]` for single-arg functions.
<ntim> (my point was `arguments.join(",")` is also extra overhead in the future, as much as `arguments.split(",")` is an overhead)
<ydaniv> ... we may have a sophisticaed syntax for multiple args, and we're trying to reduce this to whether these are args or not
<ydaniv> ntim: you will need both, in the future you'll need to collapsed string as well
<fantasai> We sometimes use commas to separate arguments, sometimes spaces. If we're trying to avoid parsing things, we should return a list of tokens even when it's space-separated.
<ydaniv> astearns: going round and round without any decision
<ydaniv> ... show of hands who would object to doing the string thing?
<ydaniv> ... seeing plinss
<TabAtkins> Yes, we use various ways, but we *also* specifically honor comma-separated arguments as something special
<fantasai> in what way?
<TabAtkins> custom functions, for example
<TabAtkins> commas separate the arglist into individual var()s
<fantasai> POLL: a) argument string b) arguments array c) neither
<ydaniv> b
<fantasai> a, c
<plinss> s/seeing plinss/seeing plinss and tabatkins/
<ydaniv> astearns: objections to use selector text?
<ydaniv> [none]
<astearns> RESOLVED: Add selectorText to the pseudo object