Skip to content

Commit e3f2b9e

Browse files
committed
[css-values-5][editorial] bikeshed fixes
1 parent 454fb25 commit e3f2b9e

File tree

1 file changed

+21
-13
lines changed

1 file changed

+21
-13
lines changed

css-values-5/Overview.bs

Lines changed: 21 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -103,7 +103,7 @@ Request URL Modifiers</h4>
103103
</dl>
104104

105105
<div algorithm>
106-
To <dfn>apply request modifiers from URL value</dfn>
106+
To <dfn export>apply request modifiers from URL value</dfn>
107107
given a [=/request=] |req|
108108
and a <<url>> |url|,
109109
call the [=request modifier steps=] for |url|'s <<request-url-modifier>>s in sequence
@@ -133,7 +133,7 @@ Interpolation Progress Functional Notations</h2>
133133
such as a [=math function=]
134134
or a [=mix notation=].
135135

136-
<h3 id="progress">
136+
<h3 id="progress-func">
137137
Calculated Progress Values: the ''progress()'' notation</h3>
138138

139139
The <dfn>progress()</dfn> functional notation
@@ -150,7 +150,7 @@ Calculated Progress Values: the ''progress()'' notation</h3>
150150
The syntax of ''progress()'' is defined as follows:
151151

152152
<pre class=prod>
153-
<dfn><<progress()>></dfn> = progress(<<calc-sum>> from <<calc-sum>> to <<calc-sum>>)
153+
<dfn id=typedef-progress-fn><<progress()>></dfn> = progress(<<calc-sum>> from <<calc-sum>> to <<calc-sum>>)
154154
</pre>
155155

156156
where the first, second, and third <<calc-sum>> values represent
@@ -167,7 +167,7 @@ Calculated Progress Values: the ''progress()'' notation</h3>
167167
Note: The ''progress()'' function is essentially syntactic sugar
168168
for a particular pattern of ''calc()'' notations.
169169

170-
<h3 id="progress">
170+
<h3 id="media-progress-func">
171171
Media Query Progress Values: the ''media-progress()'' notation</h3>
172172

173173
Similar to the ''progress()'' notation,
@@ -194,7 +194,7 @@ Media Query Progress Values: the ''media-progress()'' notation</h3>
194194
must be valid values for the specified [=media query=],
195195
or else the function is invalid.
196196

197-
<h3 id="progress">
197+
<h3 id="container-progress-func">
198198
Container Query Progress Values: the ''container-progress()'' notation</h3>
199199

200200
The <dfn>container-progress()</dfn> functional notation
@@ -228,7 +228,7 @@ Mixing and Interpolation Notations: the *-mix() family</h2>
228228
These [=functional notations=] follow the syntactic pattern:
229229

230230
<pre class=prod>
231-
<var>mix-function</var>() = <var>mix-function</var>( <<progress>>, <<start-value>>, <<end-value>> )
231+
<var>mix-function</var>() = <var>mix-function</var>( <<progress>>, [=mix start value|start-value=], [=mix end value|end-value=] )
232232
</pre>
233233

234234
The [=mix notations=] in CSS include:
@@ -256,7 +256,7 @@ Mixing and Interpolation Notations: the *-mix() family</h2>
256256
but how would we represent a set of keyframes for a [=component value=]
257257
(rather than a full property value)?
258258

259-
<h3 id="progress">
259+
<h3 id="progress-type">
260260
Representing Interpolation Progress: the <<progress>> type</h2>
261261

262262
The <dfn><<progress>></dfn> value type represents
@@ -347,7 +347,7 @@ Interpolated Numeric and Dimensional Values: the ''color-mix()'' notation</h3>
347347
<pre class=prod>
348348
<<color-mix()>> =
349349
color-mix( <<progress>> && <<color-interpolation-method>>?, <<color>>, <<color>> ) |
350-
color-mix( <<color-interpolation-method>>, [<<color>> && <<percentage[0,100]>>?]#{2} )
350+
color-mix( <<color-interpolation-method>>, [<<color>> && <<percentage [0,100]>>?]#{2} )
351351
</pre>
352352

353353
The used value of the first [=mix notation=] variant
@@ -632,12 +632,18 @@ Ian's proposal:
632632
substitutes a [=custom property=] value into a function.
633633

634634
<pre class=prod>
635-
attr() = attr( <<q-name>> <<attr-type>>? , <<declaration-value>>?)
635+
attr() = attr( <<attr-name>> <<attr-type>>? , <<declaration-value>>?)
636+
637+
<dfn>&lt;attr-name></dfn> = [ <<ident-token>> '|' ]? <<ident-token>>
636638
637639
<dfn>&lt;attr-type></dfn> = string | url | ident | color | number | percentage |
638640
length | angle | time | frequency | flex | <<dimension-unit>>
639641
</pre>
640642

643+
<!-- Switch the <attr-name> to just use <q-name>
644+
when Namespaces is rewritten
645+
to use the current grammar structures. -->
646+
641647
The <dfn>&lt;dimension-unit></dfn> production matches a literal "%" character
642648
(that is, a <<delim-token>> with a value of "%")
643649
or an ident whose value is any of the CSS units
@@ -646,8 +652,10 @@ Ian's proposal:
646652

647653
The arguments of ''attr()'' are:
648654

649-
: <<q-name>>
650-
:: Gives the name of the attribute being referenced.
655+
: <<attr-name>>
656+
:: Gives the name of the attribute being referenced,
657+
similar to <<wq-name>> (from [[SELECTORS-3]])
658+
but without the possibility of a wildcard prefix.
651659

652660
If no namespace is specified
653661
(just an identifier is given, like ''attr(foo)''),
@@ -656,7 +664,7 @@ Ian's proposal:
656664
as namespaced attributes are rare.
657665
In particular, HTML and SVG do not contain namespaced attributes.)
658666
As with [=attribute selectors=],
659-
the case-sensitivity of <<q-name>> depends on the document language.
667+
the case-sensitivity of <<attr-name>> depends on the document language.
660668

661669
If ''attr()'' is used in a property applied to an element,
662670
it references the attribute of the given name on that element;
@@ -1243,7 +1251,7 @@ Generating/Caching Random Values: the <<random-caching-options>> value</h4>
12431251
}
12441252
</pre>
12451253

1246-
But so long as the [=used-values=] end up identical,
1254+
But so long as the [=used values=] end up identical,
12471255
two functions that look distinct might end up identical.
12481256
For example, in the following code:
12491257

0 commit comments

Comments
 (0)