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

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

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> sakhapov: some pseudo-elements can ahve an argument, should we return name and arguments as one string, or separately?<br>
&lt;TabAtkins> sakhapov: right now CSSPseudoElement.type returns the name<br>
&lt;TabAtkins> sakhapov: I think it makes sense to have arguments separately, so authors don't have to parse a string<br>
&lt;flackr> q+<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> sakhapov: haven't thought too much about use-cases yet, but as a future proofing<br>
&lt;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<br>
&lt;TabAtkins> sakhapov: do you think name/arguments/name+arguments is too much?<br>
&lt;TabAtkins> flackr: dont' think it's too much<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> astearns: if you have them separatley you can reconstruct the combined<br>
&lt;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<br>
&lt;flackr> qq+<br>
&lt;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<br>
&lt;astearns> ack flackr<br>
&lt;Zakim> flackr, you wanted to react to fantasai<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> astearns: running close on time, hearing agreement that arguments should be separate at least. suggesting resolving on a spearate property, details TBD?<br>
&lt;TabAtkins> sakhapov: we can also wait for use-cases<br>
&lt;fantasai> s/so i can see/but i can also see/<br>
&lt;TabAtkins> astearns: so could leave as-is, with the *intent* to add a separat eproperty if needed<br>
&lt;TabAtkins> astearns: so let's do that.<br>
&lt;TabAtkins> flackr: also not against renaming .type<br>
&lt;TabAtkins> flackr: but i do think we should have *something* that returns the full string<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: i agree that makes sense, but do think .type should be the "type" of the pseudo-element, not its full arguments<br>
&lt;TabAtkins> fantasai: so my suggestion is .type doesn't return the params, we add another attribute that gets you the whole thing<br>
&lt;TabAtkins> astearns: we're out of time, take back to the 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/12161#issuecomment-3005322964 using your GitHub account


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

Received on Wednesday, 25 June 2025 16:01:51 UTC