- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 07:10:07 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<sakhapov> sakhapov<br>
<ydaniv> sakhapov: some context, we have pseudo interface for proxy for pseudo elements<br>
<ydaniv> ... this object always exists<br>
<ydaniv> ... it's just a proxy element, not a real one, even if you don't render anything<br>
<ydaniv> ... when you pass in a selector, can have args, question is how define properties to get the args of the pseudo element<br>
<ydaniv> ... in the last comment on the issue I have a suggestion<br>
<ydaniv> ... we do .arguments to return a list of args, or just null if none<br>
<TabAtkins> q+<br>
<emilio> q+<br>
<ydaniv> ... so that this returns a normalized text and can round-trip<br>
<ydaniv> ... maybe someone has objection to naming?<br>
<astearns> ack TabAtkins<br>
<ydaniv> TabAtkins: I think these are all good, good design, this should be a sequence OM string<br>
<ydaniv> ... I'll help to fix<br>
<astearns> ack emilio<br>
<TabAtkins> s/should be/can't be/<br>
<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<br>
<ydaniv> ... don't have on arguments vs. parameters<br>
<ydaniv> ... do we have a precedent for that?<br>
<ydaniv> TabAtkins: don't know<br>
<ydaniv> emilio: so could be either way<br>
<ydaniv> TabAtkins: I don't know what we do in CSS<br>
<ntim> css-highlights/css-pseudo/css-view-transitions probably have examples<br>
<ydaniv> emilio: bikesheding aside, selector text identfier aside, looks good<br>
<kbabbitt> ::highlight uses "argument" as well<br>
<ydaniv> astearns: what do we use for selector for a rule in CSSOM?<br>
<ydaniv> emilio: selector text, might be a better name<br>
<ydaniv> sakhapov: question about scroll buttons, whether should be logical or physical<br>
<ydaniv> emilio: separate issue<br>
<ydaniv> ... I don't know if those things alias eachother, probably discuss separately<br>
<ydaniv> astearns: I hear we're agreeing on a typed argument selector text and separate issue for scroll buttons?<br>
<astearns> s/typed argument selector text/type, arguments, selectorText/<br>
<ydaniv> emilio: if you called .pseudo and pass a selector that could select multiple things should not be allowed<br>
<ydaniv> ... the point of these are to get specific elements, so should probably just throw<br>
<ydaniv> ... for the logical vs. physical it's a bit tricky<br>
<ydaniv> sakhapov: we can discuss separately<br>
<astearns> Proposed resolution: use type, arguments, selectorText<br>
<ydaniv> emilio: arguments seems fine<br>
<ydaniv> astearns: kbabbitt said there is precedent<br>
<ydaniv> astearns: objections?<br>
<ydaniv> sakhapov: for the pseudos only one argument still return a list<br>
<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."<br>
<ydaniv> TabAtkins: currently all have one<br>
<ydaniv> ntim: if we have ones without args,<br>
<ydaniv> ... I think it's a bad pattern to have multiple args but to point to one thing<br>
<ydaniv> emilio: imagine we had a pseudo element for corners<br>
<ydaniv> [cross talk]<br>
<ydaniv> TabAtkins: arguments is a good name for this sort of thing, we will in the future have an element with multiple args<br>
<JakeA> q+<br>
<ydaniv> fantasai: I think we have it just return a string<br>
<ydaniv> TabAtkins: I rather deal with that legacy later<br>
<TabAtkins> s/I rather/I don't want to have to/<br>
<ydaniv> florian: we've done this before and not fun<br>
<JakeA> q-<br>
<ydaniv> TabAtkins: in CSS all concepts that deal with multiple args have comma separation<br>
<ydaniv> ntim: I can see in the future using commas and still only point to one thing<br>
<ydaniv> TabAtkins: don't see how these concepts are related<br>
<ydaniv> ... you can have multiple and none args<br>
<ydaniv> fantasai: it's not the parameters to a function, they just look like it<br>
<ydaniv> ... we're creating an unneccary API here<br>
<ydaniv> ntim: I can see this list becoming an identifier<br>
<ydaniv> [cross talk]<br>
<ydaniv> astearns: I think we're having difficulyt with hypothetical future stuff here<br>
<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<br>
<ydaniv> TabAtkins: sounds good!<br>
<TabAtkins> s/sounds good/sounds bad, I hate it<br>
<fantasai> +1 to astearns :)<br>
<ntim> ydaniv: s/I can see this list becoming an identifier/we could name it "identifier" instead of "argument"<br>
<florian> q?<br>
<florian> q+<br>
<ydaniv> florian: was thinking this example is more convincing<br>
<ydaniv> fantasai: question is do we use commas or spaces, and how does that appear on the IDL<br>
<TabAtkins> JS doesn't offer `.argument` and `.arguments`, with the former letting you avoid writing `[0]` for single-arg functions.<br>
<ntim> (my point was `arguments.join(",")` is also extra overhead in the future, as much as `arguments.split(",")` is an overhead)<br>
<ydaniv> ... we may have a sophisticaed syntax for multiple args, and we're trying to reduce this to whether these are args or not<br>
<ydaniv> ntim: you will need both, in the future you'll need to collapsed string as well<br>
<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.<br>
<ydaniv> astearns: going round and round without any decision<br>
<ydaniv> ... show of hands who would object to doing the string thing?<br>
<ydaniv> ... seeing plinss<br>
<TabAtkins> Yes, we use various ways, but we *also* specifically honor comma-separated arguments as something special<br>
<fantasai> in what way?<br>
<TabAtkins> custom functions, for example<br>
<TabAtkins> commas separate the arglist into individual var()s<br>
<fantasai> POLL: a) argument string b) arguments array c) neither<br>
<ydaniv> b<br>
<fantasai> a, c<br>
<plinss> s/seeing plinss/seeing plinss and tabatkins/<br>
<ydaniv> astearns: objections to use selector text?<br>
<ydaniv> [none]<br>
<astearns> RESOLVED: Add selectorText to the pseudo object<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-3531224633 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 07:10:08 UTC