[css-values] Distinction between `attr(foo type(<string>))` and `attr(foo string)` is too subtle

[nt1m]

One parses the string and strips whitespace, the other reflects the string as-is. As an author, it's hard to know what the difference is without reading documentation.

Possible ways to accommodate this:

• remove the string keyword entirely, make the attr(foo) the only way to express this
• find another keyword that makes the difference more explicit unparsed-string or as-string ?

cc @tursunova @tabatkins @fantasai

[tabatkins]

Yeah, I'm fine with a more explicit name. I would have been okay with making it only expressible via absence, but given #11818 I'd prefer if there was a way to specify it so we can get it without the legacy fallback quirk.

I think unparsed-string works well.

[fantasai]

I don't think unparsed-string is going to make much sense to most authors.

The biggest difference is actually the requirement of <string> to include the quotation marks. Like, for a literal attribute you need to double-quote the value...

[tabatkins]

Right, that's the biggest difference. Otherwise it's just that CSS string escapes would be processed by type(<string>), so <div data-foo="'bar\30 '"> would result in a string of "bar0".

(Note: it's not that type(<string>) is useful for attr(), it really isn't. But it would be weird to exclude one value of <syntax>.)

I don't think unparsed-string is going to make much sense to most authors.

Then suggest something else. ^_^

[Loirooriol]

raw-string seems better than unparsed-string to me.

[css-meeting-bot]

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

The full IRC log of that discussion

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