Re: [csswg-drafts] [css-values-5] Clarify how `<attr-unit>` should be parsed (#12479)

The CSS Working Group just discussed ``[css-values-5] Clarify how `<attr-unit>` should be parsed``, and agreed to the following:

* `RESOLVED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) are literals. Add a 'number' keyword for literal numbers.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: Right now stuff for &lt;attr-unit> production says "take this numerical attribute and pretend it's a pixel value"<br>
&lt;fantasai> TabAtkins: says to parse it as a &lt;number><br>
&lt;fantasai> TabAtkins: How literal are we about that? Is it a NUMBER token from Syntax? Or a &lt;number> value from values?<br>
&lt;fantasai> TabAtkins: the latter allows all the math functions<br>
&lt;fantasai> TabAtkins: we need to clarify the spec in either direction<br>
&lt;fantasai> TabAtkins: an earlier version of extended attr() was very specifically only looking for number tokens<br>
&lt;fantasai> TabAtkins: for implementation simplicity reasons<br>
&lt;fantasai> TabAtkins: it solved the use cases and was easy to do<br>
&lt;fantasai> TabAtkins: as you allow more complicated things, it becomes more complicated<br>
&lt;fantasai> TabAtkins: probably not worse than allowing more complexity in other values?<br>
&lt;fantasai> TabAtkins: originally we added calc(), and then a jillion more math functions<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: this brings up interesting q<br>
&lt;TabAtkins> fantasai: do we want to distinguish between CSS types (which should parse as full CSS) but have a different syntax for simple things<br>
&lt;TabAtkins> fantasai: like "just a number"<br>
&lt;emilio> q+<br>
&lt;TabAtkins> fantasai: for some core types like number... for string type we have a special type that doesn't do CSS parsing and just uses the attr value, so we already have cases for this distinction<br>
&lt;TabAtkins> fantasai: so maybe this is a case where we distinguish<br>
&lt;TabAtkins> fantasai: if you want CSS length values, use type(&lt;length>), if you want CSS numbers, use type(&lt;number.)<br>
&lt;TabAtkins> fantasai: but if you just want a number interpreted as px, use this other syntax<br>
&lt;TabAtkins> fantasai: and maybe that syntax is just the syntax we had before, with the keywords<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: What is the behavior with custom properties?<br>
&lt;fantasai> emilio: I would assume you ? parse calc() there<br>
&lt;fantasai> emilio: consistency with that would be fair<br>
&lt;TabAtkins> fantasai: this would mean any type() annotation is consistent with properties, but attr() would allow some extra things<br>
&lt;TabAtkins> emilio: agree that a raw number makes sense<br>
&lt;TabAtkins> fantasai: yeah, raw number with a unit appended, and a raw string, those are the special things we should be able to do<br>
&lt;TabAtkins> astearns: we could take a resolution to define the type() parsing and have a new issue for extending the attr() for these raw types<br>
&lt;fantasai> TabAtkins: This issue is about the unit keywords, not type() function<br>
&lt;fantasai> TabAtkins: I'm happy with the proposal, where type keywords work for raw values, and anything with type() function is a CSS parse.<br>
&lt;fantasai> TabAtkins: Probably means we want to add one more keyword for number, for raw numbers<br>
&lt;fantasai> TabAtkins: currently we have raw-string, all the units, and %<br>
&lt;fantasai> fantasai: so you're proposing raw-number?<br>
&lt;emilio> q+<br>
&lt;TabAtkins> proposed: all the unit/% keywords are "raw number" - only a literal number. Add raw-number that's the same without a unit. All type() values are CSS-parsed, so type(&lt;number>) allows calc()/etc<br>
&lt;fantasai> PROPOSED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) areliterals.<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: seems fair. I wish the keyword was just 'number'. It's a fairly common use cases, and 90% of use cases would be covered by it.<br>
&lt;fantasai> emilio: raw-string is the default, so right now you don't have to type it<br>
&lt;fantasai> TabAtkins: I'm fine with plain 'number'.<br>
&lt;fantasai> PROPOSED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) are literals. Add a 'number' keyword for literal numbers.<br>
&lt;fantasai> RESOLVED: type() values are parsed just as in custom properties. Other attr() type values (units % etc) are literals. Add a 'number' keyword for literal numbers.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12479#issuecomment-3329561248 using your GitHub account


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

Received on Wednesday, 24 September 2025 15:46:11 UTC