[css-values-5] Tweak the syntax of the attr() syntax specifier, per W…

…G resolution. #11034 #11035

css-values-5/Overview.bs

@@ -1554,11 +1554,20 @@ Ian's proposal:
 	substitutes a [=custom property=] value into a function.
 
 	<pre class=prod>
-		attr() = attr( <<attr-name>> <<syntax>>? , <<declaration-value>>?)
+		attr() = attr( <<attr-name>> <<attr-type>>? , <<declaration-value>>?)
 
 		<dfn>&lt;attr-name></dfn> = [ <<ident-token>> '|' ]? <<ident-token>>
+		<dfn>&lt;attr-type></dfn> = type( <<syntax>> ) | string | <<attr-unit>>
 	</pre>
 
+	The <dfn>&lt;attr-unit></dfn> production matches any [=identifier=]
+	that is an [=ASCII case-insensitive=] match
+	for the name of a CSS dimension unit,
+	such as ''px'',
+	or the <<delim-token>> <css>%</css>.
+	It is not expanded literally here,
+	as the set of units expands over time.
+
 	<!-- Switch the <attr-name> to just use <q-name>
 		when Namespaces is rewritten
 		to use the current grammar structures. -->
@@ -1584,23 +1593,38 @@ Ian's proposal:
 		if applied to a pseudo-element,
 		the attribute is looked up on the pseudo-element's [=originating element=].
 
-	: <<syntax>>
+	: <<attr-type>>
 	::
 		Specifies how the attribute value is [=CSS/parsed=] into a CSS value.
+
+		If given as a ''type()'' function,
+		the value is parsed according to the <<syntax>> argument,
+		and substitutes as the resulting tokens.
 		Values that fail to parse according to the syntax
 		trigger fallback.
 
-		Omitting the <<syntax>> argument
-		causes the attribute's literal value
+		If given as an <<attr-unit>> value,
+		the value is first parsed as if <css>type(&lt;number>)</css> was specified,
+		then the resulting numeric value
+		is turned into a dimension with the corresponding unit,
+		or a percentage if <css>%</css> was given.
+		Values that fail to parse as a <css>&lt;number></css>
+		trigger fallback.
+
+		If given as the <css>string</css> keyword,
+		or omitted entirely,
+		it causes the attribute's literal value
 		to be treated as the value of a CSS string,
 		with no CSS parsing performed at all
 		(including CSS escapes, whitespace removal, comments, etc).
+		No value triggers fallback;
+		only the lack of the attribute entirely does.
 
-		Note: This is different from specifying a syntax of ''*'',
+		Note: This is different from specifying a syntax of ''type(*)'',
 		which still triggers CSS parsing
 		(but with no requirements placed on it
 		beyond that it parse validly),
-		and which substitutes the result of that parsing directly,
+		and which substitutes the result of that parsing directly as tokens,
 		rather than as a <<string>> value.
 
 	: <<declaration-value>>
@@ -1645,7 +1669,7 @@ Ian's proposal:
 		}
 		stock > * {
 			display: block;
-			width: attr(length <number em>, 0px);
+			width: attr(length em, 0px);
 			height: 1em;
 			border: solid thin;
 			margin: 0.5em;
@@ -1738,7 +1762,7 @@ Security</h4>
 		However, using ''attr()'' for other purposes is fine,
 		even if the usage is <em>near</em> a url:
 
-		* ''background-image: image("foo.jpg", attr(bgcolor &lt;color>))'' is fine;
+		* ''background-image: image("foo.jpg", attr(bgcolor type(&lt;color>)))'' is fine;
 			the ''attr()'' is providing a fallback color,
 			and the <<url>> isn't [=attr()-tainted=].
 	</div>
@@ -1752,7 +1776,7 @@ Security</h4>
 	Note that non-string types can even trigger this,
 	via functions like <css>string()</css>
 	that can stringify other types of values:
-	''--foo: attr(foo number); background-image: src(string(var(--foo)))''
+	''--foo: attr(foo type(<number>)); background-image: src(string(var(--foo)))''
 	needs to be invalid as well.
 
 <!-- Big Text: random