- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Mar 2026 16:42:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] Can ident() bypass dashed-ident requirements?`, and agreed to the following:
* `RESOLVED: only allow literal strings and idents, and <number>s. for validity purposes, pretend the <number>s are "0".`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> andruud: in many places in CSS parsing we allow only a restricted type of ident e.g. dashed-ident<br>
<kbabbitt> ... today we rject things that don't match at parsed time<br>
<kbabbitt> ... with the ident function that's not possible anymore because we're blind to what it returns parse time<br>
<kbabbitt> ... question is, what do we do?<br>
<kbabbitt> ... do we allow container names for example specified with an ident() that doesn't start with --, do we allow that as a kind of "escape"?<br>
<kbabbitt> ... or do we make it IACVT for example?<br>
<kbabbitt> ... or something else?<br>
<kbabbitt> ... I think unfortunately the most reasonable answer is that we make it IACVT<br>
<lea> q+<br>
<weinig> q+<br>
<kbabbitt> ... so if you specify container-name: ident(...) then that's always valid parse time and we apply restrictions later<br>
<kbabbitt> ... this is complicated to do, because a lot of things that could not be IACVT could now become that<br>
<kbabbitt> ... but I think at least theoretically it's what makes the most sense<br>
<kbabbitt> ... that said i haven't found a reason why we couldn't just treat it as an escape<br>
<TabAtkins> What things could not have been IACVT and now are?<br>
<emilio> q+<br>
<kbabbitt> ... but worried we'd regret it later if we allowed it<br>
<astearns> ack lea<br>
<kbabbitt> lea: I don't think ident() should be treated specially compared to just specifying an ident<br>
<kbabbitt> ... confusing to tell authors they can wrap a regular ident in ident() and now it can be a dashed-ident<br>
<kbabbitt> ... if a certain syntax only accepts dashed-ident, that should remain regardless of where it came from<br>
<kbabbitt> ... ident() just produces an ident<br>
<kbabbitt> ... when the unknown is due to a var, we already have rules about that, not a problem<br>
<kbabbitt> ... we should focus discussion on where this conforms to dashed-ident when we don't have a var<br>
<kbabbitt> ... for example string + sibling-index<br>
<kbabbitt> ... there was a proposal where you replace math functions with 0 or something<br>
<kbabbitt> ... that would work in cases where dashed-ident is required<br>
<kbabbitt> ... can't think of any cases where it wouldn't<br>
<kbabbitt> ... however this kind of mock eval does seem a little wonky, makes me a little uncomfortable if we encode it in the spec<br>
<kbabbitt> ... wondering if normative text should be, UA should statically check at parse time whether this is a dashed-ident without specifying how they do mock eval<br>
<TabAtkins> q+<br>
<kbabbitt> ... could add a note that one way to do it is this way, but not encode in spec that all UAs should do it this way<br>
<kbabbitt> ... don't think we should push all cases to computed-value time, makes no sense for the feature and too restrictive for authors<br>
<kbabbitt> ... if you just have 2 strings joined, it's weird that resolves at computed-value time<br>
<kbabbitt> ... from author point of view, no reason to defer that kind of check<br>
<kbabbitt> andruud: if we have a var in there or any substitution function, computed value time is the earliers this can become invalid<br>
<kbabbitt> lea: yes, variables aside where we already have established rules<br>
<kbabbitt> andruud; we could say that resolve the ident as much as possible parse time and if that flattens into a known ident, then apply parse-time checks at that time<br>
<kbabbitt> ... a case where that would not work is typical concatenation of literal string + sibling-index<br>
<kbabbitt> ... because that resolves later<br>
<kbabbitt> emilio: but doesn't sibling-index behave as arbitrary substitution function?<br>
<kbabbitt> andruud: no<br>
<kbabbitt> emilio: shouldn't it?<br>
<kbabbitt> ... attr() is a subsetitution function and there's no problem<br>
<kbabbitt> andruud: it isn't<br>
<kbabbitt> emilio: shouldnt sibling-index behave like attr effectively<br>
<kbabbitt> ... which would pass this whole thing<br>
<TabAtkins> sibling-index() isn't important here, it's just an example "returns an integer" function<br>
<kbabbitt> ... reason I wasn't sure this why this wasn't aproblem was didn't know sibling-index was abritrary sub function<br>
<kbabbitt> ... if we make it one would that resolve<br>
<kbabbitt> andruud: should we make ident() as sub function then?<br>
<kbabbitt> emilio: would prefer not to I think<br>
<kbabbitt> ... but it's the same argument<br>
<kbabbitt> ... ident() doesn't depend on the element so you can get away with not making it a sub function<br>
<kbabbitt> ... if you find something random like calc() in there, is that supposed to work?<br>
<kbabbitt> ... my gut feeling would be ident() was naive CSS function that parses things and always resolves to an ident, nothing pending<br>
<kbabbitt> ... I think that model works for most use cases if sibling-index() and co are sub functions<br>
<lea> q?<br>
<kbabbitt> ... right?<br>
<kbabbitt> ... would that be a model that makes sense?<br>
<kbabbitt> andruud: now you're requiring all future functions to be sub functions if they return ints<br>
<lea> q+<br>
<kbabbitt> emilio: element-dependent functions ... could make them not arb sub functions but they wouldn't work on ident()<br>
<kbabbitt> ... is a use case we want something like ident("foo" calc(...))<br>
<kbabbitt> ... is that something we want to support and how? sibling-index seems similar<br>
<kbabbitt> ... if ident just takes strings and concats them, or strings and idents, very simple things that don't require this whole thing, we'll behave<br>
<kbabbitt> ... are there use cases for things that aren't arb sub functions that you would want to stash in there? don't see a lot of use cases<br>
<kbabbitt> andruud: sibling-index is one<br>
<kbabbitt> emilio: don't see why sibling-index is different to attr<br>
<kbabbitt> ... can you stash sibling-index anywhere and if not why not?<br>
<kbabbitt> ... if you can stash it anywhere, would it be simpler to make it an arb sub fn?<br>
<kbabbitt> andruud: this is a wider question<br>
<astearns> ack weinig<br>
<kbabbitt> weinig: to the last point, I think calc in ident is useful even wihtout sibling-index<br>
<TabAtkins> I'm honestly extremely confused what this arb-sub tangent is about. I don't think it has any relevance to the discussion?<br>
<kbabbitt> ... if creating a bunch of identifiers, might want some math to compute a suffix that's a number<br>
<kbabbitt> ... comment about mock evaluation<br>
<kbabbitt> ... if we're jst talking aout dash prefix, it's not a mock evaluation so much as just looking at first args to the ident<br>
<kbabbitt> ... if they are strings we can already figure out if they're dashes<br>
<kbabbitt> ... can't think of any examples other than var() where we can't<br>
<lea> qq+<br>
<kbabbitt> ... excluding that, can't think of any examples where it's not trivial to look for -- at the beginning<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to react to weinig<br>
<kbabbitt> lea: I can think of an example<br>
<emilio> q-<br>
<kbabbitt> ... if we have a custom counter style that adds hyphens and use that counter in the beginning, then whether ident is dashed-ident depends on counter value<br>
<astearns> ack TabAtkins<br>
<kbabbitt> TabAtkins: one little bit, I don't like this mock evaluation idea<br>
<kbabbitt> ... don't think it's necessary, but lea mentoined not specifying details and I'm extremely allergic to that<br>
<kbabbitt> ... have to have dependable behavior between browsers<br>
<kbabbitt> ... my feeling about this is, if we have it be IACVT anywhere, it should be dependable and not subject to subtle aspects of what you're specifying<br>
<kbabbitt> ... if it's a string, can eval that immediately and turn into a literal string<br>
<kbabbitt> ... but if you have some functions that might not compute yet, I'd prefer, regardless of what they are, treat them as potentially IACVT<br>
<kbabbitt> ... rather than subtly slice up if we can infer this could be a dashed-ident, fail immediately or not<br>
<kbabbitt> ... don't like subtle parsing details that can't help authors<br>
<kbabbitt> ... still confused about arb sub fun though<br>
<kbabbitt> ... andruud said this could expose IACVT behvaior to places that didn't have it before<br>
<astearns> s/arb sub fun/arbitrary substitution function discussion/<br>
<kbabbitt> ... don't understand why because anyplace that could accept it could accept a var()<br>
<emilio> q+<br>
<kbabbitt> andruud: that was a note about impl difficulty, not author experience<br>
<kbabbitt> TabAtkins: okay, you refer to a wrinkle to this I don't understand<br>
<kbabbitt> andruud: in order for something to be possibly IACVT today you must have an arb sub fn somewhere<br>
<kbabbitt> ... now an ident is not a sub fn, suddenly can be IACVT<br>
<kbabbitt> ... not saying we have to give up on it in advance, just saying it's new<br>
<kbabbitt> ... we already have one other case in anchor but it's very narrow<br>
<astearns> ack lea<br>
<astearns> ack emilio<br>
<emilio> My proposal would be: make ident() take just `<string> | <ident> | <integer-token>` (or so), and make `sibling-index()` and co arbitrary substitution function. If you need `calc()` or what not you can get around it with `@property` / `var()`<br>
<weinig> q+<br>
<kbabbitt> emilio: agree with andruud that ... I would make this simpler and make sibling-index an arb sub fn<br>
<TabAtkins> ??? I still dont' understand what Emilio is talking about :(<br>
<kbabbitt> ... and if you need math you can use a registered custom prop and var9)<br>
<kbabbitt> ... feels to me like allowing arbitrary math in there is kind of annoying, conceptually as soon as you allow int you already have a deferred thing<br>
<kbabbitt> ... might have addition of em by something else and now you have to wait until em resolve<br>
<kbabbitt> ... that's similarly annoying impl wise<br>
<kbabbitt> ... would rather keep ident() simple, if the big use case is sibling-index, since that needs to wait until computed-value time to resolve anyway, obvious thing is to make it an arbitrary sub fun<br>
<kbabbitt> ... maybe more flexible? can think of ways where a random int wouldn't be valid<br>
<andruud> Another example is random()<br>
<kbabbitt> ... I think that covers all the use cases and removes this problem<br>
<kbabbitt> TabAtkins: if you're saying we should make ident an arb sub fn, I agree that solves things in general<br>
<kbabbitt> ... but you keep talking about specific functions returning int becoming arb sub and I don't get it<br>
<kbabbitt> emilio: point is, if we make ident() an arb sub fn, would also sidestep this issue but in a different way<br>
<kbabbitt> ... it's nice to be able to reject ident() at parse time if you know you're not expecting an ident<br>
<kbabbitt> ... to me, main difference is, ident() on its own doesn't depend on anything else other than its args<br>
<kbabbitt> ... if we restrict the args and it still covers use cases, you can reject at parse time very easily<br>
<kbabbitt> ... sibling-index() etc. it's impossible to not defer computation<br>
<kbabbitt> ... whole reason attr() was made an arb sub fn is, it's extremely annoying to deal with this in all the places that potentially need attr()<br>
<kbabbitt> ... to keep it as a regular parsed value<br>
<kbabbitt> ... arb sub fns fit well with that use case of something we need to defer unconditionally<br>
<lea> q+<br>
<kbabbitt> ... easier to poke into that machinery than whack-amole whole codebase<br>
<kbabbitt> TabAtkins: agree with that<br>
<kbabbitt> emilio: this is another case where sibling-index() fits in with that, still need to deal with that everywhere you take ints<br>
<kbabbitt> ... not a huge issue but if it propagates annoyance to ident() etc. maybe the easy thing is to restrict ident() to keep as simple as possible and make sibling-index() asf<br>
<kbabbitt> TabAtkins: not sure doing anything to sibling-index() will solve the issue<br>
<kbabbitt> emilio: my proposal had an integer token thing<br>
<kbabbitt> TabAtkins: if you want sibling-index() just as reasonable to use random() for specific integers<br>
<kbabbitt> emilio: not a fan of random() for a variety of reasons<br>
<astearns> ack weinig<br>
<kbabbitt> weinig: not super familiar with counter, wanted to understand that example better<br>
<kbabbitt> ... seems on the face that counter can't evaluate until computed value time, so acts as an asf in that regard<br>
<kbabbitt> emilio: counter doesn't resolve to an integer<br>
<kbabbitt> ... resolves to a string<br>
<kbabbitt> ... not at computed value time<br>
<kbabbitt> ... only when you build layout tree do you evaluate those<br>
<kbabbitt> weinig: so the counter example isn't a counter-example<br>
<kbabbitt> andruud: relevant but actually a separate issue, even worswe<br>
<kbabbitt> ... about stuff we can't resolve at computed value time<br>
<kbabbitt> weinig: so it wouldn't be supported inside ident()<br>
<kbabbitt> andruud: noe<br>
<kbabbitt> weinig: think it's a trivial operation to define to figure out if there are two dashes as a prefix<br>
<lea> +1 weinig<br>
<kbabbitt> ... as a rule if we can avoid IACVT it's better because it's confusing for authors<br>
<astearns> ack lea<br>
<TabAtkins> q+ for a proposal, then<br>
<kbabbitt> lea: +1 to what weinig said about avoiding IACVT if we can<br>
<kbabbitt> ... woudl support any subset of cases to be determined at parse time over making everything resolved at CV time if some cases need to wait<br>
<kbabbitt> ... not sure how we could rule out counter in general since it returns a string<br>
<kbabbitt> ... would we just not parse counter inside ident?<br>
<kbabbitt> emilio: doesn't return a string<br>
<kbabbitt> ... computes to a counter() function<br>
<kbabbitt> TabAtkins: kind of a used value thing<br>
<kbabbitt> lea: at used value time doesn't it return a string?<br>
<kbabbitt> emilio: hand wavy but yes<br>
<kbabbitt> lea: if what's inside the ident needs to wait until CV time, let's wait<br>
<kbabbitt> ... if everything can be checked at parsed value time that would make the most sense<br>
<emilio> q+<br>
<kbabbitt> ... fewer things we have to make asfs the better<br>
<kbabbitt> ... fewer things that resolve at CV time the better<br>
<kbabbitt> andruud: can't wait until UV time, not practical<br>
<kbabbitt> emilio: scroll-timeline needs to be known at style time<br>
<kbabbitt> andruud: can open separate issue for this<br>
<astearns> ack TabAtkins<br>
<Zakim> TabAtkins, you wanted to discuss a proposal, then<br>
<kbabbitt> TabAtkins: do we have a great reason to allow non-literal strings?<br>
<kbabbitt> ... outside of counter, a custom fn that returns a string, is that problematic?<br>
<kbabbitt> emilio: custom fns are not problematic because they behave as vars<br>
<kbabbitt> ... if we restrict everything to literals ident() is trivial to implement<br>
<kbabbitt> TabAtkins: my proposal is indeed that<br>
<kbabbitt> ... we restrict ident() to literal strings and numeric functoins<br>
<kbabbitt> ... and do mock evaluation stuff where, for purpose of determining validity, treat function as digit 0<br>
<kbabbitt> ... if that forms a valid keyword for that context<br>
<kbabbitt> ... at parse time, you are good<br>
<kbabbitt> ... otherwise you are invalid immediately<br>
<lea> q+<br>
<kbabbitt> ... we can on a case by case basis in the future, take anu non asf string fns and determie if they should be allowed<br>
<kbabbitt> ... bt want to be careful about this<br>
<lea> q-<br>
<weinig> +1 to tab's proposal<br>
<kbabbitt> ... big uses casesa are strings and dynamic integers both of which should be fine<br>
<lea> +1 to TabAtkins's proposal<br>
<kbabbitt> ... if we can cover those 2 use cases we should be fine<br>
<lea> q+<br>
<kbabbitt> emilio: not sure that works great because if you have a negative number can't you do "-" then negative number<br>
<kbabbitt> TabAtkins: 1000% okay with that being invalid<br>
<romain> +1 to this being invalid :D<br>
<kbabbitt> TabAtkins: if you want to put a - in front of a hopefully negative number that will form a dashed-ident, what are you doing, just put -- like a normal person<br>
<kbabbitt> emilio: weird to reject that at parse time when it would be valid at CV time<br>
<kbabbitt> ... feels like big use case for dynamic stuff in ident() are sibling-index, random, but random already needs to wait for CV time<br>
<kbabbitt> TabAtkins: sometimes<br>
<kbabbitt> emilio: you cannot resolve random at parse time by definition, right?<br>
<kbabbitt> TabAtkins: theoretically resolvable at parse time, but yeah<br>
<astearns> ack emilio<br>
<kbabbitt> astearns: we've been discussing for half hour and it's evolved into at least one other issue<br>
<kbabbitt> emilio: not a fan of treating every number as 0, feels a bit weird<br>
<TabAtkins> proposal: only allow literal strings, and <number>s. for validity purposes, pretend the <number>s are "0".<br>
<kbabbitt> ... to me, simple thing is make ident() as simple as possible<br>
<kbabbitt> ... can use asf thing for other things<br>
<kbabbitt> ... fine if you're not a fan of that<br>
<kbabbitt> ... you're making same arg I make for ints for strings<br>
<kbabbitt> ... why not take it all the way, ident is always parse timeable<br>
<lea> (FWIW, anecdotally none of the use cases I have come across involve sibling-index() or random() )<br>
<kbabbitt> TabAtkins: always parse timeable under my proposal but if you're depending on a negative number plus a - it's a false negative<br>
<kbabbitt> ... seems like a use case we don't need to worry about<br>
<kbabbitt> emilio: would it be invalid if you had a var there?<br>
<kbabbitt> ... suppose you had a var that resolves to a negative number<br>
<kbabbitt> TabAtkins: that would still be invalid<br>
<kbabbitt> emilio: as long as we're consistent, not that terrible<br>
<kbabbitt> lea: +1 to TabAtkins proposal<br>
<astearns> ack lea<br>
<kbabbitt> ... seems reasonable to me<br>
<kbabbitt> ... most use cases I've come across are strings and numbers<br>
<kbabbitt> ... idents with other idents would still be alllowed?<br>
<kbabbitt> TabAtkins: ye<br>
<kbabbitt> lea; assuming these idents and strings can come from vars as well<br>
<kbabbitt> ... taht seems to cover every use case I've come across<br>
<kbabbitt> ... would still be useful to have a list of what wouldn't be allowed<br>
<kbabbitt> ... but seems like a good compromise<br>
<kbabbitt> astearns: my understanding is taht this would be a stepping stone, might not ever allow more stuff in ident but could on case by case basis<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> TabAtkins: all asfs work by definition<br>
<kbabbitt> lea; what wouldn't be allowed<br>
<kbabbitt> TabAtkins: counter and I don't know what others we have that return strings<br>
<TabAtkins> proposal: only allow literal strings, and <number>s. for validity purposes, pretend the <number>s are "0".<br>
<TabAtkins> proposal: only allow literal strings and idents, and <number>s. for validity purposes, pretend the <number>s are "0".<br>
<kbabbitt> astearns: saw a bunch of +1s in IRC go by, any questions?<br>
<kbabbitt> astearns: objections?<br>
<kbabbitt> +1 from me for now<br>
<kbabbitt> RESOLVED: only allow literal strings and idents, and <number>s. for validity purposes, pretend the <number>s are "0".<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12206#issuecomment-3998743769 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 March 2026 16:42:35 UTC