Re: [csswg-drafts] [css-values] Distinction between `attr(foo type(<string>))` and `attr(foo string)` is too subtle (#11645)

The CSS Working Group just discussed ``[css-values] Distinction between `attr(foo type(<string>))` and `attr(foo string)` is too subtle``, and agreed to the following:

* `RESOLVED: Rename string keyword to raw-string`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: attr() has the ability to say how to parse the attribute<br>
&lt;fantasai> TabAtkins: default behavior is to take the value and use it directly as a string<br>
&lt;fantasai> TabAtkins: we also have the ability to parse it as CSS value<br>
&lt;fantasai> TabAtkins: In particular, can parse it as a string. This is weird, because you would need to include the quotes.<br>
&lt;fantasai> TabAtkins: But it would also be weird to exclude that, so we're allowing it.<br>
&lt;fantasai> TabAtkins: But it's confusing because to get the first behavior you write 'string' and for the second behavior you write 'type(&lt;string>)'<br>
&lt;fantasai> TabAtkins: These are super close to each other, and probably confusing for authors.<br>
&lt;fantasai> TabAtkins: Some discussion about other keywords.<br>
&lt;fantasai> TabAtkins: unparsed-string, raw-string ...<br>
&lt;bkardell_> sgtm<br>
&lt;fantasai> TabAtkins: Unless anyone has other ideas, propose to rename to raw-string<br>
&lt;fantasai> TabAtkins: this is one of the keywords that do special behaviors<br>
&lt;TabAtkins> attr(href raw-string)<br>
&lt;fantasai> fantasai: this is equivalent to attr(href)<br>
&lt;fantasai> astearns: If it's equivalent to syntax without keyword, can we just remove the keyword?<br>
&lt;fantasai> TabAtkins: We can't. For one thing, I prefer having explicit keywords. But more importantly, legacy behavior requires us to fall back to an empty string if the attribute is missing<br>
&lt;fantasai> TabAtkins: whereas the new behavior is falling back to Invalid At Computed Time behavior.<br>
&lt;fantasai> TabAtkins: It would be weird if you couldn't do that for the most common case<br>
&lt;fantasai> TabAtkins: so omitting falls back to empty string, including keyword falls back to IACT<br>
&lt;kbabbitt> fantasai: that is a subtle difference that is not going to be obvious at all<br>
&lt;kbabbitt> fantasai: if that's actually a behavioral difference I think it would be good to make it clearer<br>
&lt;kbabbitt> TabAtkins: don't know how to bake IACVT into a keyword<br>
&lt;kbabbitt> fantasai: me either<br>
&lt;kbabbitt> TabAtkins: right now if you specify a type at all you get IACVT as a fallback<br>
&lt;kbabbitt> TabAtkins: not tied to string vs ??, a little more for people to learn<br>
&lt;kbabbitt> TabAtkins: agree it's not great but need to work around legacy behavior<br>
&lt;fantasai> fantasai: Something for us to think about, if we can make it clearer.<br>
&lt;fantasai> astearns: So for now, proposal is to rename to raw-string<br>
&lt;fantasai> TabAtkins: Should do asap, since we're shipping already.<br>
&lt;bkardell_> +Q<br>
&lt;bkardell_> q-<br>
&lt;bkardell_> 1+<br>
&lt;fantasai> astearns: any objections to changing string to raw-string?<br>
&lt;fantasai> RESOLVED: Rename string keyword to raw-string<br>
</details>


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


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

Received on Wednesday, 5 March 2025 17:24:33 UTC