Re: [csswg-drafts] [css-values] attr()'s type system is inconsistent with other things (#10437)

The CSS Working Group just discussed `[css-values] attr()'s type system is inconsistent with other things`, and agreed to the following:

* `RESOLVED: Use the <syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> moonira: in attr() grammer we define without angle brackets which is inconsistent with other custom property syntax<br>
&lt;kbabbitt> ... we have a prototype of attr() in Blink which we are going to ship<br>
&lt;kbabbitt> ... propose to resolve this issue by making attr() consistent with @property using angle brackets<br>
&lt;kbabbitt> TabAtkins: want to make sure all the places use consistent syntax; attr() was designed before we came up with this other stuff<br>
&lt;kbabbitt> astearns: and this is ocnsistent ewith type decision we made earlier<br>
&lt;kbabbitt> TabAtkins: yes<br>
&lt;lea> +1 seems like an obvious win to me<br>
&lt;kbabbitt> astearns: questions?<br>
&lt;chrishtr> q+<br>
&lt;kbabbitt> Proposed: Use the &lt;syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties<br>
&lt;flackr> +1 sgtm<br>
&lt;kbabbitt> lea: (missed)<br>
&lt;fantasai> +!<br>
&lt;astearns> ack chrishtr<br>
&lt;fantasai> s/!/1/<br>
&lt;astearns> s/(missed)/consistent with custom properties etc.<br>
&lt;kbabbitt> chrishtr: question, this is new syntax for attr() and there's no compatibility risk with existing websites?<br>
&lt;kbabbitt> moonira: I don't think it should be a problem<br>
&lt;kbabbitt> chrishtr: attr exists, but it's just not exposed<br>
&lt;kbabbitt> moonira: existing attr() version doesn't include type syntax<br>
&lt;kbabbitt> chrishtr: what you're planning to ship will have type syntax?<br>
&lt;kbabbitt> moonira: correct<br>
&lt;kbabbitt> chrishtr: so because it's new syntax, there will not be a compat concern?<br>
&lt;kbabbitt> moonira: yes<br>
&lt;kbabbitt> astearns: other commments or questions?<br>
&lt;kbabbitt> hober: you're right, everyone has simple attr() that's it, should be good. but...<br>
&lt;kbabbitt> ... older spec has had other syntax for a long time, authors do like to do the cool thing they hope will work eventually<br>
&lt;kbabbitt> ... so there is potentially a compat risk, there may be things that were invalid before and would have been ignored<br>
&lt;kbabbitt> chrishtr: good point, it's possible but it seems worth trying to me<br>
&lt;kbabbitt> dbaron: I think it might even be less scary to change it just because suddenly implementing a feature if authors have been trying to write it and not test it for a long time is scary<br>
&lt;TabAtkins> we don't *usually* account for people writing invalid stuff ahead of the spec unless we're pretty sure there's actually a problem<br>
&lt;kizu> +1<br>
&lt;kbabbitt> ... changing the syntax right befor eit ships helps with that<br>
&lt;kbabbitt> chrishtr: are there other older features that have not been shipped with similar conditions?<br>
&lt;kbabbitt> tabatkins: no additional locations, just @property, @function, attr()<br>
&lt;TabAtkins> @property @function and @tr<br>
&lt;kbabbitt> astearns: objections?<br>
&lt;kbabbitt> RESOLVED: Use the &lt;syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties<br>
&lt;matthieud> q+<br>
&lt;astearns> ack matthieud<br>
&lt;lea> q+<br>
&lt;kbabbitt> matthieud: for @property we need to put the syntax in quotes, but for attr() and @function we don't need uqoes?<br>
&lt;kbabbitt> tabatkins: no, @property will be updated<br>
&lt;kbabbitt> lea: the string versio will strictly be more powerful because you can still do quantifiers and htings like that?<br>
&lt;kbabbitt> tabatkins: no, you'll be able to use th enew syntax prodyction<br>
&lt;kbabbitt> lea: can you use quantifiers, e.g. 0-5?<br>
&lt;kbabbitt> tabatkins: I don't think that's in the grammer but it's not supported for the string version either<br>
&lt;kbabbitt> ... (missed0<br>
&lt;TabAtkins> like &lt;number [0, 5]><br>
</details>


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


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

Received on Thursday, 26 September 2024 18:17:45 UTC