Re: [csswg-drafts] [css-values-5] attr() and forwards compatible parsing (#11035)

The CSS Working Group just discussed `[css-values-5] attr() and forwards compatible parsing`, and agreed to the following:

* `RESOLVED: Accept proposal to use type(<syntax>), add string, and add units as keywords.`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Scribenick: fantasai<br>
&lt;fantasai> TabAtkins: We switched attr() to use type definition syntax, similar to variables<br>
&lt;fantasai> TabAtkins: But working through that, we lost some abilities<br>
&lt;fantasai> TabAtkins: for example, saying the attr is a number representing px values<br>
&lt;fantasai> TabAtkins: It started to get too complicated for common cases<br>
&lt;fantasai> TabAtkins: For grammar ambiguity reasons, we suggest to wrap in type() function<br>
&lt;fantasai> TabAtkins: and end up with a lot for simple cases.<br>
&lt;fantasai> TabAtkins: Suggestion is to keep the &lt;syntax> argument, but wrapped in type()<br>
&lt;fantasai> TabAtkins: but for two cases we have an easier way to specify<br>
&lt;fantasai> TabAtkins: for default behavior of treating attr value as a string, we introduce a keyword (string) so you can say so explicitly<br>
&lt;fantasai> TabAtkins: and secondly, add all units as keywords, which parse as a number and attach that unit<br>
&lt;fantasai> TabAtkins: this does slightly reduce the power of the syntax compared to before, since can't mix this behavior with other values<br>
&lt;fantasai> TabAtkins: but I think it's OK, not a high-value use case right now; can evaluate later or add to &lt;syntax> production<br>
&lt;fantasai> TabAtkins: but instead of type(&lt;number px>) can just write px, much simpler<br>
&lt;fantasai> TabAtkins: so proposal is<br>
&lt;fantasai> 1. Add type() wrapper around &lt;syntax><br>
&lt;Rossen0> q?<br>
&lt;kizu> +1 to the proposal<br>
&lt;fantasai> 2. Introduce string keyword for explicitly indicating string parsing<br>
&lt;chrishtr> +1<br>
&lt;fantasai> 3. Add all units to attach to a &lt;number><br>
&lt;lea> I don't understand the proposed options<br>
&lt;TabAtkins> attr(foo type(&lt;length>))<br>
&lt;TabAtkins> attr(foo string) (deffault behavior)<br>
&lt;fantasai> attr(attributename [ type(&lt;syntax>) | string | &lt;unit> ], fallback)<br>
&lt;TabAtkins> attr(foo type(*))<br>
&lt;fantasai> lea: can you parse in a token stream?<br>
&lt;fantasai> TabAtkins: yes, use * just like in custom properties<br>
&lt;ydaniv> +1<br>
&lt;fantasai> lea: what's without the proposal?<br>
&lt;fantasai> attr(attributename &lt;syntax>, fallback)<br>
&lt;fantasai> TabAtkins: wanted to wrap type() because &lt;syntax> would make parsing complicated if we add anything in the future<br>
&lt;fantasai> lea: could we use keyword instead of type()?<br>
&lt;florian> wfm<br>
&lt;fantasai> TabAtkins: using type() because that's what we do in custom functions<br>
&lt;fantasai> TabAtkins: thought about using 'as' but consistency is good<br>
&lt;fantasai> lea: no way to use 'as' in functions? presumably want to know where the syntax terminates<br>
&lt;fantasai> TabAtkins: yes, and in some cases if you want to accept several keywords...<br>
&lt;fantasai> TabAtkins: having type() wrapper makes it clearer<br>
&lt;lea> +1<br>
&lt;TabAtkins> attr(foo type(one | two | three))<br>
&lt;oriol> +1<br>
&lt;fantasai> wfm<br>
&lt;fantasai> Rossen0: Anyone else? Any objections?<br>
&lt;fantasai> RESOLVED: Accept proposal to use type(&lt;syntax>), add string, and add units as keywords.<br>
</details>


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


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

Received on Wednesday, 13 November 2024 17:54:31 UTC