@@ -1554,11 +1554,20 @@ Ian's proposal:
15541554 substitutes a [=custom property=] value into a function.
15551555
15561556 <pre class=prod>
1557- attr() = attr( <<attr-name>> <<syntax >> ? , <<declaration-value>> ?)
1557+ attr() = attr( <<attr-name>> <<attr-type >> ? , <<declaration-value>> ?)
15581558
15591559 <dfn><attr-name></dfn> = [ <<ident-token>> '|' ]? <<ident-token>>
1560+ <dfn><attr-type></dfn> = type( <<syntax>> ) | string | <<attr-unit>>
15601561 </pre>
15611562
1563+ The <dfn><attr-unit></dfn> production matches any [=identifier=]
1564+ that is an [=ASCII case-insensitive=] match
1565+ for the name of a CSS dimension unit,
1566+ such as ''px'' ,
1567+ or the <<delim-token>> <css> %</css> .
1568+ It is not expanded literally here,
1569+ as the set of units expands over time.
1570+
15621571 <!-- Switch the <attr-name> to just use <q-name>
15631572 when Namespaces is rewritten
15641573 to use the current grammar structures. -->
@@ -1584,23 +1593,38 @@ Ian's proposal:
15841593 if applied to a pseudo-element,
15851594 the attribute is looked up on the pseudo-element's [=originating element=] .
15861595
1587- : <<syntax >>
1596+ : <<attr-type >>
15881597 ::
15891598 Specifies how the attribute value is [=CSS/parsed=] into a CSS value.
1599+
1600+ If given as a ''type()'' function,
1601+ the value is parsed according to the <<syntax>> argument,
1602+ and substitutes as the resulting tokens.
15901603 Values that fail to parse according to the syntax
15911604 trigger fallback.
15921605
1593- Omitting the <<syntax>> argument
1594- causes the attribute's literal value
1606+ If given as an <<attr-unit>> value,
1607+ the value is first parsed as if <css> type(<number>)</css> was specified,
1608+ then the resulting numeric value
1609+ is turned into a dimension with the corresponding unit,
1610+ or a percentage if <css> %</css> was given.
1611+ Values that fail to parse as a <css> <number></css>
1612+ trigger fallback.
1613+
1614+ If given as the <css> string</css> keyword,
1615+ or omitted entirely,
1616+ it causes the attribute's literal value
15951617 to be treated as the value of a CSS string,
15961618 with no CSS parsing performed at all
15971619 (including CSS escapes, whitespace removal, comments, etc).
1620+ No value triggers fallback;
1621+ only the lack of the attribute entirely does.
15981622
1599- Note: This is different from specifying a syntax of ''* '' ,
1623+ Note: This is different from specifying a syntax of ''type(*) '' ,
16001624 which still triggers CSS parsing
16011625 (but with no requirements placed on it
16021626 beyond that it parse validly),
1603- and which substitutes the result of that parsing directly,
1627+ and which substitutes the result of that parsing directly as tokens ,
16041628 rather than as a <<string>> value.
16051629
16061630 : <<declaration-value>>
@@ -1645,7 +1669,7 @@ Ian's proposal:
16451669 }
16461670 stock > * {
16471671 display: block;
1648- width: attr(length <number em> , 0px);
1672+ width: attr(length em , 0px);
16491673 height: 1em;
16501674 border: solid thin;
16511675 margin: 0.5em;
@@ -1738,7 +1762,7 @@ Security</h4>
17381762 However, using ''attr()'' for other purposes is fine,
17391763 even if the usage is <em> near</em> a url:
17401764
1741- * ''background-image: image("foo.jpg", attr(bgcolor <color>))'' is fine;
1765+ * ''background-image: image("foo.jpg", attr(bgcolor type( <color>) ))'' is fine;
17421766 the ''attr()'' is providing a fallback color,
17431767 and the <<url>> isn't [=attr()-tainted=] .
17441768 </div>
@@ -1752,7 +1776,7 @@ Security</h4>
17521776 Note that non-string types can even trigger this,
17531777 via functions like <css> string()</css>
17541778 that can stringify other types of values:
1755- ''--foo: attr(foo number); background-image: src(string(var(--foo)))''
1779+ ''--foo: attr(foo type(< number>) ); background-image: src(string(var(--foo)))''
17561780 needs to be invalid as well.
17571781
17581782<!-- Big Text: random
0 commit comments