changeset
[css-syntax] Merge and update the Changes sections.
Mon, 03 Jun 2013 15:59:38 +0900
- author
- Simon Sapin <simon.sapin@exyr.org>
- date
- Mon, 03 Jun 2013 15:59:38 +0900
- changeset 8323
- 78bfd2eb8013
- parent 8322
- f6aeb4c4dd41
- child 8324
- 6a24538736c9
[css-syntax] Merge and update the Changes sections.
| css-syntax/Overview.html | file | annotate | diff | comparison | revisions | |
| css-syntax/Overview.src.html | file | annotate | diff | comparison | revisions |
1.1 --- a/css-syntax/Overview.html Fri May 31 13:52:41 2013 -0700 1.2 +++ b/css-syntax/Overview.html Mon Jun 03 15:59:38 2013 +0900 1.3 @@ -11,7 +11,7 @@ 1.4 1.5 <meta content="CSS Syntax Module Level 3 (CSS3 Syntax)" name=dcterms.title> 1.6 <meta content=text name=dcterms.type> 1.7 - <meta content=2013-05-31 name=dcterms.date> 1.8 + <meta content=2013-06-03 name=dcterms.date> 1.9 <meta content="Tab Atkins Jr." name=dcterms.creator> 1.10 <meta content=W3C name=dcterms.publisher> 1.11 <meta content="http://dev.w3.org/csswg/css3-syntax/" 1.12 @@ -32,7 +32,7 @@ 1.13 <h1 class=p-name>CSS Syntax Module Level 3</h1> 1.14 1.15 <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft <time 1.16 - class=dt-updated datetime=20130531>31 May 2013</time></h2> 1.17 + class=dt-updated datetime=20130603> 3 June 2013</time></h2> 1.18 1.19 <dl> 1.20 <dt>This version: 1.21 @@ -234,9 +234,6 @@ 1.22 <li><a href="#set-the-unicode-ranges-range"><span class=secno>4.3.15. 1.23 </span> Set the 〈unicode-range〉’s range</a> 1.24 </ul> 1.25 - 1.26 - <li><a href="#changes-from-css-2.1-tokenizer"><span class=secno>4.4. 1.27 - </span> Changes from CSS 2.1 Tokenizer</a> 1.28 </ul> 1.29 1.30 <li><a href="#parsing"><span class=secno>5. </span> Parsing</a> 1.31 @@ -293,9 +290,6 @@ 1.32 <li><a href="#consume-a-function"><span class=secno>5.4.8. </span> 1.33 Consume a function</a> 1.34 </ul> 1.35 - 1.36 - <li><a href="#changes-from-css-2.1-core-grammar"><span class=secno>5.5. 1.37 - </span> Changes from CSS 2.1 Core Grammar</a> 1.38 </ul> 1.39 1.40 <li><a href="#anb"><span class=secno>6. </span> The <var>An+B</var> 1.41 @@ -324,12 +318,15 @@ 1.42 Serializing <var><an+b></var></a> 1.43 </ul> 1.44 1.45 - <li><a href="#conformance"><span class=secno>9. </span> Conformance</a> 1.46 + <li><a href="#changes"><span class=secno>9. </span>Changes from CSS 2.1 1.47 + and Selectors Level 3</a> 1.48 + 1.49 + <li><a href="#conformance"><span class=secno>10. </span> Conformance</a> 1.50 <ul class=toc> 1.51 - <li><a href="#conventions"><span class=secno>9.1. </span> Document 1.52 + <li><a href="#conventions"><span class=secno>10.1. </span> Document 1.53 conventions</a> 1.54 1.55 - <li><a href="#conformance-classes"><span class=secno>9.2. </span> 1.56 + <li><a href="#conformance-classes"><span class=secno>10.2. </span> 1.57 Conformance classes</a> 1.58 </ul> 1.59 1.60 @@ -2375,47 +2372,7 @@ 1.61 between the character whose codepoint is the <a 1.62 href="#start-of-the-range"><i>start of the range</i></a> and the 1.63 character whose codepoint is the <a href="#end-of-the-range"><i>end of 1.64 - the range</i></a>. 1.65 - 1.66 - <h3 id=changes-from-css-2.1-tokenizer><span class=secno>4.4. </span> 1.67 - Changes from CSS 2.1 Tokenizer</h3> 1.68 - 1.69 - <p> <em>This section is non-normative.</em> 1.70 - 1.71 - <p class=note> Note that the point of this spec is to match reality; 1.72 - changes from CSS2.1’s tokenizer are nearly always because the 1.73 - tokenizer specified something that doesn't match actual browser 1.74 - behavior, or left something unspecified. If some detail doesn't match 1.75 - browsers, please let me know as it's almost certainly unintentional. 1.76 - 1.77 - <ol> 1.78 - <li> The 〈prefix-match〉, 〈suffix-match〉, and 1.79 - 〈substring-match〉 tokens have been imported from Selectors 3. 1.80 - 1.81 - <li> The BAD-URI token (now 〈bad-url〉) is "self-contained". In 1.82 - other words, once the tokenizer realizes it's in a 〈bad-url〉 1.83 - rather than a 〈url〉, it just seeks forward to look for the 1.84 - closing ), ignoring everything else. This behavior is simpler than 1.85 - treating it like a 〈function〉 and paying attention to opened 1.86 - blocks and such. Only WebKit exhibits this behavior, but it doesn't 1.87 - appear that we've gotten any compat bugs from it. 1.88 - 1.89 - <li> The 〈comma〉 has been added. 1.90 - 1.91 - <li> The 〈number〉, 〈number〉, and 〈dimension〉 tokens have 1.92 - been changed to include the preceding +/- sign as part of their value 1.93 - (rather than as a separate 〈delim〉 that needs to be manually 1.94 - handled every time the token is mentioned in other specs). The only 1.95 - consequence of this is that comments can no longer be inserted 1.96 - between the sign and the number. 1.97 - 1.98 - <li> Scientific notation is supported for 1.99 - numbers/percentages/dimensions to match SVG, per WG resolution. 1.100 - 1.101 - <li> 〈column〉 has been added, to keep Selectors parsing in 1.102 - single-token lookahead. 1.103 - </ol> 1.104 - <!-- 1.105 + the range</i></a>. <!-- 1.106 PPPPPPPPPPPPPPPPP AAA RRRRRRRRRRRRRRRRR SSSSSSSSSSSSSSS EEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRR 1.107 P::::::::::::::::P A:::A R::::::::::::::::R SS:::::::::::::::SE::::::::::::::::::::ER::::::::::::::::R 1.108 P::::::PPPPPP:::::P A:::::A R::::::RRRRRR:::::R S:::::SSSSSS::::::SE::::::::::::::::::::ER::::::RRRRRR:::::R 1.109 @@ -3398,18 +3355,652 @@ 1.110 value</i></a> and append the returned value to the function's value. 1.111 </dl> 1.112 1.113 - <h3 id=changes-from-css-2.1-core-grammar><span class=secno>5.5. </span> 1.114 - Changes from CSS 2.1 Core Grammar</h3> 1.115 + <h2 id=anb><span class=secno>6. </span> The <a 1.116 + href="#anb0"><var>An+B</var></a> microsyntax</h2> 1.117 + 1.118 + <p> Several things in CSS, such as the ‘<code 1.119 + class=css>:nth-child()</code>’ pseudoclass, need to indicate indexes 1.120 + in a list. The <a href="#anb0"><var>An+B</var></a> microsyntax is 1.121 + useful for this, allowing an author to easily indicate single elements 1.122 + or all elements at regularly-spaced intervals in a list. 1.123 + 1.124 + <p> The <dfn id=anb0>An+B</dfn> notation defines an integer step (<dfn 1.125 + id=a>A</dfn>) and offset (<dfn id=b>B</dfn>), and represents the <a 1.126 + href="#anb0"><var>An+B</var></a>th elements in a list, for every 1.127 + positive integer or zero value of <var>n</var>, with the first element 1.128 + in the list having index 1 (not 0). 1.129 + 1.130 + <p> For values of <a href="#a"><var>A</var></a> and <a 1.131 + href="#b"><var>B</var></a> greater than 0, this effectively divides 1.132 + the list into groups of <a href="#a"><var>A</var></a> elements (the 1.133 + last group taking the remainder), and selecting the <a 1.134 + href="#b"><var>B</var></a>th element of each group. 1.135 + 1.136 + <p> The <a href="#anb0"><var>An+B</var></a> notation also accepts the 1.137 + ‘<code class=css>even</code>’ and ‘<code class=css>odd</code>’ 1.138 + keywords, which have the same meaning as ‘<code 1.139 + class=css>2n</code>’ and ‘<code class=css>2n+1</code>’, 1.140 + respectively. 1.141 + 1.142 + <div class=example> 1.143 + <p>Examples: 1.144 + 1.145 + <pre><!-- 1.146 + -->2n+0 /* represents all of the even elements in the list */ 1.147 +<!-- 1.148 + -->even /* same */ 1.149 +<!-- 1.150 + -->4n+1 /* represents the 1st, 5th, 9th, 13th, etc. elements in the list */</pre> 1.151 + </div> 1.152 + 1.153 + <p> The values of <a href="#a"><var>A</var></a> and <a 1.154 + href="#b"><var>B</var></a> can be negative, but only the positive 1.155 + results of <a href="#anb0"><var>An+B</var></a>, for <var>n</var> ≥ 1.156 + 0, are used. 1.157 + 1.158 + <div class=example> 1.159 + <p>Example: 1.160 + 1.161 + <pre>-n+6 /* represents the first 6 elements of the list */</pre> 1.162 + </div> 1.163 + 1.164 + <p> If both <a href="#a"><var>A</var></a> and <a 1.165 + href="#b"><var>B</var></a> are 0, the pseudo-class represents no 1.166 + element in the list. 1.167 + 1.168 + <h3 id=anb-syntax><span class=secno>6.1. </span> Informal Syntax 1.169 + Description</h3> 1.170 + 1.171 + <p><em>This section is non-normative.</em> 1.172 + 1.173 + <p> When <a href="#a"><var>A</var></a> is 0, the <var>An</var> part may 1.174 + be omitted (unless the <a href="#b"><var>B</var></a> part is already 1.175 + omitted). When <var>An</var> is not included and <a 1.176 + href="#b"><var>B</var></a> is non-negative, the ‘<code 1.177 + class=css>+</code>’ sign before <a href="#b"><var>B</var></a> (when 1.178 + allowed) may also be omitted. In this case the syntax simplifies to 1.179 + just <a href="#b"><var>B</var></a>. 1.180 + 1.181 + <div class=example> 1.182 + <p>Examples: 1.183 + 1.184 + <pre><!-- 1.185 + -->0n+5 /* represents the 5th element in the list */ 1.186 +<!-- 1.187 + -->5 /* same */</pre> 1.188 + </div> 1.189 + 1.190 + <p> When <a href="#a"><var>A</var></a> is 1 or -1, the <code>1</code> 1.191 + may be omitted from the rule. 1.192 + 1.193 + <div class=example> 1.194 + <p>Examples: 1.195 + 1.196 + <p>The following notations are therefore equivalent: 1.197 + 1.198 + <pre><!-- 1.199 + -->1n+0 /* represents all elements in the list */ 1.200 +<!-- 1.201 + -->n+0 /* same */ 1.202 +<!-- 1.203 + -->n /* same */</pre> 1.204 + </div> 1.205 + 1.206 + <p> If <a href="#b"><var>B</var></a> is 0, then every <a 1.207 + href="#a"><var>A</var></a>th element is picked. In such a case, the <a 1.208 + href="#b"><var>+B</var></a> (or <var>-B</var>) part may be omitted 1.209 + unless the <a href="#a"><var>A</var></a> part is already omitted. 1.210 + 1.211 + <div class=example> 1.212 + <p>Examples: 1.213 + 1.214 + <pre><!-- 1.215 + -->2n+0 /* represents every even element in the list */ 1.216 +<!-- 1.217 + -->2n /* same */</pre> 1.218 + </div> 1.219 + 1.220 + <p> Whitespace is permitted on either side of the ‘<code 1.221 + class=css>+</code>’ or ‘<code class=css>-</code>’ that separates 1.222 + the <var>An</var> and <a href="#b"><var>B</var></a> parts when both 1.223 + are present. 1.224 + 1.225 + <div class=example> 1.226 + <p>Valid Examples with white space: 1.227 + 1.228 + <pre><!-- 1.229 + -->3n + 1 1.230 +<!-- 1.231 + -->+3n - 2 1.232 +<!-- 1.233 + -->-n+ 6 1.234 +<!-- 1.235 + -->+6</pre> 1.236 + 1.237 + <p>Invalid Examples with white space: 1.238 + 1.239 + <pre><!-- 1.240 + -->3 n 1.241 +<!-- 1.242 + -->+ 2n 1.243 +<!-- 1.244 + -->+ 2</pre> 1.245 + </div> 1.246 + 1.247 + <h3 id=the-anb-type><span class=secno>6.2. </span> The <a 1.248 + href="#anb-production"><code><an+b></code></a> type</h3> 1.249 + 1.250 + <p> The <a href="#anb0"><var>An+B</var></a> notation was originally 1.251 + defined using a slightly different tokenizer than the rest of CSS, 1.252 + resulting in a somewhat odd definition when expressed in terms of CSS 1.253 + tokens. This section describes how to recognize the <a 1.254 + href="#anb0"><var>An+B</var></a> notation in terms of CSS tokens (thus 1.255 + defining the <a href="#anb-production"><var><an+b></var></a> type 1.256 + for CSS grammar purposes), and how to interpret the CSS tokens to 1.257 + obtain values for <a href="#a"><var>A</var></a> and <a 1.258 + href="#b"><var>B</var></a>. 1.259 + 1.260 + <p> The <a href="#anb-production"><var><an+b></var></a> type is 1.261 + defined (using the <a 1.262 + href="http://www.w3.org/TR/css3-values/#value-defs">Value Definition 1.263 + Syntax in the Values & Units spec</a>) as: 1.264 + 1.265 + <pre class=prod> 1.266 +<dfn id=anb-production><an+b></dfn> = 1.267 + odd | even | 1.268 + <a 1.269 + href="#ltinteger"><var><integer></var></a> | 1.270 + 1.271 + <a 1.272 + href="#ltn-dimension"><var><n-dimension></var></a> | 1.273 + '+'? n | 1.274 + -n | 1.275 + 1.276 + <a 1.277 + href="#ltndashdigit-dimension"><var><ndashdigit-dimension></var></a> | 1.278 + '+'? <a 1.279 + href="#ltndashdigit-ident"><var><ndashdigit-ident></var></a> | 1.280 + <a 1.281 + href="#ltdashndashdigit-ident"><var><dashndashdigit-ident></var></a> | 1.282 + 1.283 + <a 1.284 + href="#ltn-dimension"><var><n-dimension></var></a> <a 1.285 + href="#ltsigned-integer"><var><signed-integer></var></a> | 1.286 + '+'? n <a 1.287 + href="#ltsigned-integer"><var><signed-integer></var></a> | 1.288 + -n <a 1.289 + href="#ltsigned-integer"><var><signed-integer></var></a> | 1.290 + 1.291 + <a 1.292 + href="#ltn-dimension"><var><n-dimension></var></a> ['+' | '-'] <a 1.293 + href="#ltsignless-integer"><var><signless-integer></var></a> 1.294 + '+'? n ['+' | '-'] <a 1.295 + href="#ltsignless-integer"><var><signless-integer></var></a> | 1.296 + -n ['+' | '-'] <a 1.297 + href="#ltsignless-integer"><var><signless-integer></var></a></pre> 1.298 + 1.299 + <p> where: 1.300 + 1.301 + <ul> 1.302 + <li><dfn id=ltn-dimension><code><n-dimension></code></dfn> is a 1.303 + 〈dimension〉 with its type flag set to "integer", and a unit that 1.304 + is an <a href="#ascii-case-insensitive"><i>ASCII 1.305 + case-insensitive</i></a> match for "n" 1.306 + 1.307 + <li><dfn 1.308 + id=ltndashdigit-dimension><code><ndashdigit-dimension></code></dfn> 1.309 + is a 〈dimension〉 with its type flag set to "integer", and a unit 1.310 + that is an <a href="#ascii-case-insensitive"><i>ASCII 1.311 + case-insensitive</i></a> match for "n-*", where "*" is a series of 1.312 + one or more <a href="#digit"><i>digits</i></a> 1.313 + 1.314 + <li><dfn 1.315 + id=ltndashdigit-ident><code><ndashdigit-ident></code></dfn> is an 1.316 + 〈ident〉 whose representation is an <a 1.317 + href="#ascii-case-insensitive"><i>ASCII case-insensitive</i></a> 1.318 + match for "n-*", where "*" is a series of one or more <a 1.319 + href="#digit"><i>digits</i></a> 1.320 + 1.321 + <li><dfn 1.322 + id=ltdashndashdigit-ident><code><dashndashdigit-ident></code></dfn> 1.323 + is an 〈ident〉 whose representation is an <a 1.324 + href="#ascii-case-insensitive"><i>ASCII case-insensitive</i></a> 1.325 + match for "-n-*", where "*" is a series of one or more <a 1.326 + href="#digit"><i>digits</i></a> 1.327 + 1.328 + <li><dfn id=ltinteger><code><integer></code></dfn> is a 1.329 + 〈number〉 with its type flag set to "integer" 1.330 + 1.331 + <li><dfn id=ltsigned-integer><code><signed-integer></code></dfn> is 1.332 + a 〈number〉 with its type flag set to "integer", and whose 1.333 + representation starts with "+" or "-" 1.334 + 1.335 + <li><dfn 1.336 + id=ltsignless-integer><code><signless-integer></code></dfn> is a 1.337 + 〈number〉 with its type flag set to "integer", and whose 1.338 + representation start with a <a href="#digit"><i>digit</i></a> 1.339 + </ul> 1.340 + 1.341 + <p> The clauses of the production are interpreted as follows: 1.342 + 1.343 + <dl> 1.344 + <dt>‘<code class=css>odd</code>’ 1.345 + 1.346 + <dd> <a href="#a"><var>A</var></a> is 2, <a href="#b"><var>B</var></a> 1.347 + is 1. 1.348 + 1.349 + <dt>‘<code class=css>even</code>’ 1.350 + 1.351 + <dd> <a href="#a"><var>A</var></a> is 2, <a href="#b"><var>B</var></a> 1.352 + is 0. 1.353 + 1.354 + <dt><a href="#ltinteger"><code><var><integer></var></code></a> 1.355 + 1.356 + <dd> <a href="#a"><var>A</var></a> is 0, <a href="#b"><var>B</var></a> 1.357 + is the integer. 1.358 + 1.359 + <dt><a 1.360 + href="#ltn-dimension"><code><var><n-dimension></var></code></a> 1.361 + 1.362 + <dt><code>'+'? n</code> 1.363 + 1.364 + <dt><code>-n</code> 1.365 + 1.366 + <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.367 + respectively. <a href="#b"><var>B</var></a> is 0. 1.368 + 1.369 + <dt><a 1.370 + href="#ltndashdigit-dimension"><code><var><ndashdigit-dimension></var></code></a> 1.371 + 1.372 + <dt><code>'+'? <a 1.373 + href="#ltndashdigit-ident"><var><ndashdigit-ident></var></a></code> 1.374 + 1.375 + <dt><a 1.376 + href="#ltdashndashdigit-ident"><code><var><dashndashdigit-ident></var></code></a> 1.377 + 1.378 + <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.379 + respectively. <a href="#b"><var>B</var></a> is the dimension's unit 1.380 + or ident's representation, as appropriate, with the first two 1.381 + characters removed and the remainder interpreted as a base-10 number. 1.382 + 1.383 + <dt><code><a href="#ltn-dimension"><var><n-dimension></var></a> <a 1.384 + href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.385 + 1.386 + <dt><code>'+'? n <a 1.387 + href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.388 + 1.389 + <dt><code>-n <a 1.390 + href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.391 + 1.392 + <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.393 + respectively. <a href="#b"><var>B</var></a> is the integer. 1.394 + 1.395 + <dt><code><a href="#ltn-dimension"><var><n-dimension></var></a> 1.396 + ['+' | '-'] <a 1.397 + href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.398 + 1.399 + <dt><code>'+'? n ['+' | '-'] <a 1.400 + href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.401 + 1.402 + <dt><code>-n ['+' | '-'] <a 1.403 + href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.404 + 1.405 + <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.406 + respectively. <a href="#b"><var>B</var></a> is the integer. If a 1.407 + ‘<code class=property>-</code>’ was provided between the two, <a 1.408 + href="#b"><var>B</var></a> is instead the negation of the integer. 1.409 + </dl> 1.410 + 1.411 + <h2 id=rule-defs><span class=secno>7. </span> Defining Grammars for 1.412 + Rules and Other Values</h2> 1.413 + 1.414 + <p> The <a href="http://www.w3.org/TR/css3-values/">Values</a> spec 1.415 + defines how to specify a grammar for properties. This section does the 1.416 + same, but for rules. 1.417 + 1.418 + <p> Just like in property grammars, the notation <code><foo></code> 1.419 + refers to the "foo" grammar term, assumed to be defined elsewhere. 1.420 + Substituting the <code><foo></code> for its definition results in a 1.421 + semantically identical grammar. 1.422 + 1.423 + <p> Several types of tokens are written literally, without quotes: 1.424 + 1.425 + <ul> 1.426 + <li>〈Ident〉s (such as ‘<code class=css>auto</code>’, ‘<code 1.427 + class=css>disc</code>’, etc.) 1.428 + 1.429 + <li>〈at-keyword〉s, which are written as an @ character followed by 1.430 + the token's name, like "@media". 1.431 + 1.432 + <li>〈function〉s, which are written as the function name followed 1.433 + by a ( character, like "translate(". 1.434 + 1.435 + <li>The 〈colon〉 (written as <code>:</code>), 〈comma〉 (written 1.436 + as <code>,</code>), 〈semicolon〉 (written as <code>;</code>), 1.437 + 〈(〉, 〈)〉, 〈{〉, and 〈}〉s. 1.438 + </ul> 1.439 + 1.440 + <p> 〈delim〉s are written with their value enclosed in single 1.441 + quotes. For example, a 〈delim〉 containing the "+" character is 1.442 + written as <code>'+'</code>. Similarly, the 〈[〉 and 〈]〉s must 1.443 + be written in single quotes, as they're used by the syntax of the 1.444 + grammar itself to group clauses. 〈whitespace〉 is never indicated 1.445 + in the grammar; 〈whitespace〉s are allowed before, after, and 1.446 + between any two tokens, unless explicitly specified otherwise in prose 1.447 + definitions. (For example, if the prelude of a rule is a selector, 1.448 + whitespace is significant.) 1.449 + 1.450 + <p> When defining a function or a block, the ending token must be 1.451 + specified in the grammar, but if it's not present in the eventual 1.452 + token stream, it still matches. 1.453 + 1.454 + <div class=example> For example, the syntax of the ‘<code 1.455 + class=css>translateX()</code>’ function is: 1.456 + <pre>translateX( <translation-value> )</pre> 1.457 + 1.458 + <p> However, the stylesheet may end with the function unclosed, like: 1.459 + 1.460 + <pre>.foo { transform: translate(50px</pre> 1.461 + 1.462 + <p> The CSS parser parses this as a style rule containing one 1.463 + declaration, whose value is a function named "translate". This 1.464 + matches the above grammar, even though the ending token didn't appear 1.465 + in the token stream, because by the time the parser is finished, the 1.466 + presence of the ending token is no longer possible to determine; all 1.467 + you have is the fact that there's a block and a function. 1.468 + </div> 1.469 + 1.470 + <h3 id=declaration-rule-list><span class=secno>7.1. </span> Defining 1.471 + Block Contents: the <a 1.472 + href="#ltdeclaration-list"><var><declaration-list></var></a>, <a 1.473 + href="#ltrule-list"><var><rule-list></var></a>, and <a 1.474 + href="#ltstylesheet"><var><stylesheet></var></a> productions</h3> 1.475 + 1.476 + <p> The CSS parser is agnostic as to the contents of blocks, such as 1.477 + those that come at the end of some at-rules. Defining the generic 1.478 + grammar of the blocks in terms of tokens is non-trivial, but there are 1.479 + dedicated and unambiguous algorithms defined for parsing this. 1.480 + 1.481 + <p> The <dfn 1.482 + id=ltdeclaration-list><var><declaration-list></var></dfn> 1.483 + production represents a list of declarations. It may only be used in 1.484 + grammars as the sole value in a block, and represents that the 1.485 + contents of the block must be parsed using the <a 1.486 + href="#consume-a-list-of-declarations0"><i>consume a list of 1.487 + declarations</i></a> algorithm. 1.488 + 1.489 + <p> Similarly, the <dfn id=ltrule-list><var><rule-list></var></dfn> 1.490 + production represents a list of rules, and may only be used in 1.491 + grammars as the sole value in a block. It represents that the contents 1.492 + of the block must be parsed using the <a 1.493 + href="#consume-a-list-of-rules0"><i>consume a list of rules</i></a> 1.494 + algorithm. 1.495 + 1.496 + <p> Finally, the <dfn id=ltstylesheet><var><stylesheet></var></dfn> 1.497 + production represents a list of rules. It is identical to <a 1.498 + href="#ltrule-list"><var><rule-list></var></a>, except that blocks 1.499 + using it default to accepting all rules that aren't otherwise limited 1.500 + to a particular context. 1.501 + 1.502 + <div class=example> For example, the ‘<code 1.503 + class=css>@font-face</code>’ rule is defined to have an empty 1.504 + prelude, and to contain a list of declarations. This is expressed with 1.505 + the following grammar: 1.506 + <pre>@font-face { <declaration-list> }</pre> 1.507 + 1.508 + <p> This is a complete and sufficient definition of the rule's 1.509 + grammar. 1.510 + 1.511 + <p> For another example, ‘<code class=css>@keyframes</code>’ rules 1.512 + are more complex, interpreting their prelude as a name and containing 1.513 + keyframes rules in their block Their grammar is: 1.514 + 1.515 + <pre>@keyframes <keyframes-name> { <rule-list> }</pre> 1.516 + </div> 1.517 + 1.518 + <p> For rules that use <a 1.519 + href="#ltdeclaration-list"><var><declaration-list></var></a>, the 1.520 + spec for the rule must define which properties, descriptors, and/or 1.521 + at-rules are valid inside the rule; this may be as simple as saying 1.522 + "The @foo rule accepts the properties/descriptors defined in this 1.523 + specification/section.", and extension specs may simply say "The @foo 1.524 + rule additionally accepts the following properties/descriptors.". Any 1.525 + declarations or at-rules found inside the block that are not defined 1.526 + as valid must be removed from the rule's value. 1.527 + 1.528 + <p> Within a <a 1.529 + href="#ltdeclaration-list"><var><declaration-list></var></a>, 1.530 + <code>!important</code> is automatically invalid on any descriptors. 1.531 + If the rule accepts properties, the spec for the rule must define 1.532 + whether the properties interact with the cascade, and with what 1.533 + specificity. If they don't interact with the cascade, properties 1.534 + containing <code>!important</code> are automatically invalid; 1.535 + otherwise using <code>!important</code> is valid and has its usual 1.536 + effect on the cascade origin of the property. 1.537 + 1.538 + <div class=example> For example, the grammar for ‘<code 1.539 + class=css>@font-face</code>’ in the previous example must, in 1.540 + addition to what is written there, define that the allowed 1.541 + declarations are the descriptors defined in the Fonts spec.</div> 1.542 + 1.543 + <p> For rules that use <a 1.544 + href="#ltrule-list"><var><rule-list></var></a>, the spec for the 1.545 + rule must define what types of rules are valid inside the rule, same 1.546 + as <a href="#ltdeclaration-list"><var><declaration-list></var></a>, 1.547 + and unrecognized rules must similarly be removed from the rule's 1.548 + value. 1.549 + 1.550 + <div class=example> For example, the grammar for ‘<code 1.551 + class=css>@keyframes</code>’ in the previous example must, in 1.552 + addition to what is written there, define that the only allowed rules 1.553 + are <var><keyframe-rule></var>s, which are defined as: 1.554 + <pre><keyframe-rule> = <keyframe-selector> { <declaration-list> }</pre> 1.555 + 1.556 + <p> Keyframe rules, then, must further define that they accept as 1.557 + declarations all animatable CSS properties, plus the ‘<code 1.558 + class=property>animation-timing-function</code>’ property, but that 1.559 + they do not interact with the cascade. 1.560 + </div> 1.561 + 1.562 + <p> For rules that use <a 1.563 + href="#ltstylesheet"><var><stylesheet></var></a>, all rules are 1.564 + allowed by default, but the spec for the rule may define what types of 1.565 + rules are <em>invalid</em> inside the rule. 1.566 + 1.567 + <div class=example> For example, the ‘<code 1.568 + class=css>@media</code>’ rule accepts anything that can be placed in 1.569 + a stylesheet, except more ‘<code class=css>@media</code>’ rules. 1.570 + As such, its grammar is: 1.571 + <pre>@media <media-query-list> { <stylesheet> }</pre> 1.572 + 1.573 + <p> It additionally defines a restriction that the <a 1.574 + href="#ltstylesheet"><var><stylesheet></var></a> can not contain 1.575 + ‘<code class=css>@media</code>’ rules, which causes them to be 1.576 + dropped from the outer rule's value if they appear. 1.577 + </div> 1.578 + 1.579 + <h2 id=serialization><span class=secno>8. </span>Serialization</h2> 1.580 + 1.581 + <p> This specification does not define how to serialize CSS in general, 1.582 + leaving that task to the CSSOM and individual feature specifications. 1.583 + However, there is one important facet that must be specified here 1.584 + regarding comments, to ensure accurate "round-tripping" of data from 1.585 + text to CSS objects and back. 1.586 + 1.587 + <p> The tokenizer described in this specification does not produce 1.588 + tokens for comments, or otherwise preserve them in any way. 1.589 + Implementations may preserve the contents of comments and their 1.590 + location in the token stream. If they do, this preserved information 1.591 + must have no effect on the parsing step, but must be serialized in its 1.592 + position as "/*" followed by its contents followed by "*/". 1.593 + 1.594 + <p> If the implementation does not preserve comments, it must insert 1.595 + the text "/**/" between the serialization of adjacent tokens when the 1.596 + two tokens are of the following pairs: 1.597 + 1.598 + <ul> 1.599 + <li> a 〈hash〉 or 〈at-keyword〉 followed by a 〈number〉, 1.600 + 〈percentage〉, 〈ident〉, 〈dimension〉, 〈unicode-range〉, 1.601 + 〈url〉, or a 〈function〉 token; 1.602 + 1.603 + <li> 〈number〉s, 〈ident〉s, and 〈dimension〉s in any 1.604 + combination; 1.605 + 1.606 + <li> a 〈number〉, 〈ident〉, or 〈dimension〉 followed by a 1.607 + 〈percentage〉, 〈unicode-range〉, 〈url〉, or 〈function〉; 1.608 + 1.609 + <li> an 〈ident〉 followed by a 〈(〉; 1.610 + 1.611 + <li> a 〈delim〉 containing "#" or "@" followed by any token except 1.612 + 〈whitespace〉; 1.613 + 1.614 + <li> a 〈delim〉 containing "-", "+", ".", "<", ">", or "!" 1.615 + following or followed by any token except 〈whitespace〉; 1.616 + 1.617 + <li> a 〈delim〉 containing "/" following or followed by a 1.618 + 〈delim〉 containing "*". 1.619 + </ul> 1.620 + 1.621 + <p class=note> The preceding pairs of tokens can only be adjacent due 1.622 + to comments in the original text, so the above rule reinserts the 1.623 + minimum number of comments into the serialized text to ensure an 1.624 + accurate round-trip. (Roughly. The 〈delim〉 rules are slightly too 1.625 + powerful, for simplicity.) 1.626 + 1.627 + <h3 id=serializing-anb><span class=secno>8.1. </span> Serializing <a 1.628 + href="#anb-production"><var><an+b></var></a></h3> 1.629 + 1.630 + <p> To serialize an <a href="#anb-production"><var><an+b></var></a> 1.631 + value, let <var>s</var> initially be the empty string: 1.632 + 1.633 + <dl> 1.634 + <dt><a href="#a"><var>A</var></a> and <a href="#b"><var>B</var></a> 1.635 + are both zero 1.636 + 1.637 + <dd> Append "0" to <var>s</var>. 1.638 + 1.639 + <dt><a href="#a"><var>A</var></a> is zero, <a 1.640 + href="#b"><var>B</var></a> is non-zero 1.641 + 1.642 + <dd> Serialize <a href="#b"><var>B</var></a> and append it to 1.643 + <var>s</var>. 1.644 + 1.645 + <dt><a href="#a"><var>A</var></a> is non-zero, <a 1.646 + href="#b"><var>B</var></a> is zero 1.647 + 1.648 + <dd> Serialize <a href="#a"><var>A</var></a> and append it to 1.649 + <var>s</var>. Append "n" to <var>s</var>. 1.650 + 1.651 + <dt><a href="#a"><var>A</var></a> and <a href="#b"><var>B</var></a> 1.652 + are both non-zero 1.653 + 1.654 + <dd> Serialize <a href="#a"><var>A</var></a> and append it to 1.655 + <var>s</var>. Append "n" to <var>s</var>. If <a 1.656 + href="#b"><var>B</var></a> is positive, append "+" to <var>s</var> 1.657 + Serialize <a href="#b"><var>B</var></a> and append it to 1.658 + <var>s</var>. 1.659 + </dl> 1.660 + 1.661 + <p> Return <var>s</var>. 1.662 + 1.663 + <h2 id=changes><span class=secno>9. </span>Changes from CSS 2.1 and 1.664 + Selectors Level 3</h2> 1.665 1.666 <p> <em>This section is non-normative.</em> 1.667 1.668 <p class=note> Note that the point of this spec is to match reality; 1.669 - changes from CSS2.1’s Core Grammar are nearly always because the 1.670 - Core Grammar specified something that doesn't match actual browser 1.671 - behavior, or left something unspecified. If some detail doesn't match 1.672 - browsers, please let me know as it's almost certainly unintentional. 1.673 - 1.674 - <ol> 1.675 + changes from CSS2.1 are nearly always because CSS 2.1 specified 1.676 + something that doesn't match actual browser behavior, or left 1.677 + something unspecified. If some detail doesn't match browsers, please 1.678 + let me know as it's almost certainly unintentional. 1.679 + 1.680 + <p> Changes in decoding from a byte stream: 1.681 + 1.682 + <ul> 1.683 + <li> Only detect ‘<code class=css>@charset</code>’ rules in 1.684 + ASCII-compatible byte patterns. 1.685 + 1.686 + <li> Ignore ‘<code class=css>@charset</code>’ rules that specify 1.687 + an ASCII-incompatible encoding, as that would cause the rule itself 1.688 + to not decode properly. 1.689 + 1.690 + <li> Refer to the the <a 1.691 + href="http://encoding.spec.whatwg.org/">Encoding Standard</a> rather 1.692 + than the IANA registery for character encodings. 1.693 + </ul> 1.694 + 1.695 + <p> Tokenization changes: 1.696 + 1.697 + <ul> 1.698 + <li> Any U+0000 NULL character in the CSS source is replaced with 1.699 + U+FFFD REPLACEMENT CHARACTER. 1.700 + 1.701 + <li> Any hexadecimal escape sequence such as ‘<code 1.702 + class=css>\0</code>’ that evaluate to zero produce U+FFFD 1.703 + REPLACEMENT CHARACTER rather than U+0000 NULL. <!-- 1.704 + This covers a security issue: 1.705 + https://bugzilla.mozilla.org/show_bug.cgi?id=228856 1.706 + --> 1.707 + 1.708 + <li> The definition of <a href="#non-ascii-character"><i>non-ASCII 1.709 + character</i></a> was changed to be consistent with every definition 1.710 + of ASCII. This affects characters U+0080 to U+009F, which are now <a 1.711 + href="#name-character"><i>name characters</i></a> rather than 1.712 + 〈delim〉s, like the rest of <a 1.713 + href="#non-ascii-character"><i>non-ASCII characters</i></a>. 1.714 + 1.715 + <li> Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore. 1.716 + BAD_COMMENT is now considered the same as normal token (not an 1.717 + error.) <a href="#serialization">Serialization</a> is responsible for 1.718 + inserting comments as necessary between tokens that need to be 1.719 + separated, e.g. two consecutive 〈ident〉s. 1.720 + 1.721 + <li> The 〈unicode-range〉 token is now more restrictive. <span 1.722 + class=issue>Should it? I can’t find a case where this change is 1.723 + even testable.</span> <span class=issue>Align the definition with the 1.724 + Fonts spec.</span> 1.725 + 1.726 + <li> Apply the <a 1.727 + href="http://www.w3.org/TR/CSS21/syndata.html#unexpected-eof">EOF 1.728 + error handling rule</a> in the tokenizer and emit normal 〈string〉 1.729 + and 〈url〉 tokens rather than BAD_STRING or BAD_URI on EOF. 1.730 + 1.731 + <li> The 〈prefix-match〉, 〈suffix-match〉, and 1.732 + 〈substring-match〉 tokens have been imported from Selectors 3. 1.733 + 1.734 + <li> The BAD_URI token (now 〈bad-url〉) is "self-contained". In 1.735 + other words, once the tokenizer realizes it's in a 〈bad-url〉 1.736 + rather than a 〈url〉, it just seeks forward to look for the 1.737 + closing ), ignoring everything else. This behavior is simpler than 1.738 + treating it like a 〈function〉 and paying attention to opened 1.739 + blocks and such. Only WebKit exhibits this behavior, but it doesn't 1.740 + appear that we've gotten any compat bugs from it. 1.741 + 1.742 + <li> The 〈comma〉 has been added. 1.743 + 1.744 + <li> The 〈number〉, 〈number〉, and 〈dimension〉 tokens have 1.745 + been changed to include the preceding +/- sign as part of their value 1.746 + (rather than as a separate 〈delim〉 that needs to be manually 1.747 + handled every time the token is mentioned in other specs). The only 1.748 + consequence of this is that comments can no longer be inserted 1.749 + between the sign and the number. 1.750 + 1.751 + <li> Scientific notation is supported for 1.752 + numbers/percentages/dimensions to match SVG, per WG resolution. 1.753 + 1.754 + <li> 〈column〉 has been added, to keep Selectors parsing in 1.755 + single-token lookahead. 1.756 + </ul> 1.757 + 1.758 + <p> Parsing changes: 1.759 + 1.760 + <ul> 1.761 + <li> Any list of declaration now also accepts at-rules, like ‘<code 1.762 + class=css>@page</code>’, per WG resolution. This makes a difference 1.763 + in error handling even if no such at-rules are defined yet: an 1.764 + at-rule, valid or not, ends and lets the next declaration being at a 1.765 + {} block without a 〈semicolon〉. 1.766 + 1.767 <li> The handling of some miscellanous "special" tokens (like an 1.768 unmatched 〈}〉) showing up in various places in the grammar has 1.769 been specified with some reasonable behavior shown by at least one 1.770 @@ -3425,7 +4016,12 @@ 1.771 <li> Selectors and at-rule preludes can now contain 1.772 〈at-keyword〉s 1.773 </ul> 1.774 - 1.775 + </ul> 1.776 + 1.777 + <p> <a href="#anb0"><var>An+B</var></a> changes from Selectors Level 3 1.778 + <a href="#SELECT" rel=biblioentry>[SELECT]<!--{{SELECT}}--></a>: 1.779 + 1.780 + <ul> 1.781 <li> The <a href="#anb0"><var>An+B</var></a> microsyntax has now been 1.782 formally defined in terms of CSS tokens, rather than with a separate 1.783 tokenizer. This has resulted in minor differences: 1.784 @@ -3439,555 +4035,8 @@ 1.785 they appear as part of the unit of a 〈dimension〉 or 1.786 〈ident〉). 1.787 </ul> 1.788 - </ol> 1.789 - 1.790 - <h2 id=anb><span class=secno>6. </span> The <a 1.791 - href="#anb0"><var>An+B</var></a> microsyntax</h2> 1.792 - 1.793 - <p> Several things in CSS, such as the ‘<code 1.794 - class=css>:nth-child()</code>’ pseudoclass, need to indicate indexes 1.795 - in a list. The <a href="#anb0"><var>An+B</var></a> microsyntax is 1.796 - useful for this, allowing an author to easily indicate single elements 1.797 - or all elements at regularly-spaced intervals in a list. 1.798 - 1.799 - <p> The <dfn id=anb0>An+B</dfn> notation defines an integer step (<dfn 1.800 - id=a>A</dfn>) and offset (<dfn id=b>B</dfn>), and represents the <a 1.801 - href="#anb0"><var>An+B</var></a>th elements in a list, for every 1.802 - positive integer or zero value of <var>n</var>, with the first element 1.803 - in the list having index 1 (not 0). 1.804 - 1.805 - <p> For values of <a href="#a"><var>A</var></a> and <a 1.806 - href="#b"><var>B</var></a> greater than 0, this effectively divides 1.807 - the list into groups of <a href="#a"><var>A</var></a> elements (the 1.808 - last group taking the remainder), and selecting the <a 1.809 - href="#b"><var>B</var></a>th element of each group. 1.810 - 1.811 - <p> The <a href="#anb0"><var>An+B</var></a> notation also accepts the 1.812 - ‘<code class=css>even</code>’ and ‘<code class=css>odd</code>’ 1.813 - keywords, which have the same meaning as ‘<code 1.814 - class=css>2n</code>’ and ‘<code class=css>2n+1</code>’, 1.815 - respectively. 1.816 - 1.817 - <div class=example> 1.818 - <p>Examples: 1.819 - 1.820 - <pre><!-- 1.821 - -->2n+0 /* represents all of the even elements in the list */ 1.822 -<!-- 1.823 - -->even /* same */ 1.824 -<!-- 1.825 - -->4n+1 /* represents the 1st, 5th, 9th, 13th, etc. elements in the list */</pre> 1.826 - </div> 1.827 - 1.828 - <p> The values of <a href="#a"><var>A</var></a> and <a 1.829 - href="#b"><var>B</var></a> can be negative, but only the positive 1.830 - results of <a href="#anb0"><var>An+B</var></a>, for <var>n</var> ≥ 1.831 - 0, are used. 1.832 - 1.833 - <div class=example> 1.834 - <p>Example: 1.835 - 1.836 - <pre>-n+6 /* represents the first 6 elements of the list */</pre> 1.837 - </div> 1.838 - 1.839 - <p> If both <a href="#a"><var>A</var></a> and <a 1.840 - href="#b"><var>B</var></a> are 0, the pseudo-class represents no 1.841 - element in the list. 1.842 - 1.843 - <h3 id=anb-syntax><span class=secno>6.1. </span> Informal Syntax 1.844 - Description</h3> 1.845 - 1.846 - <p><em>This section is non-normative.</em> 1.847 - 1.848 - <p> When <a href="#a"><var>A</var></a> is 0, the <var>An</var> part may 1.849 - be omitted (unless the <a href="#b"><var>B</var></a> part is already 1.850 - omitted). When <var>An</var> is not included and <a 1.851 - href="#b"><var>B</var></a> is non-negative, the ‘<code 1.852 - class=css>+</code>’ sign before <a href="#b"><var>B</var></a> (when 1.853 - allowed) may also be omitted. In this case the syntax simplifies to 1.854 - just <a href="#b"><var>B</var></a>. 1.855 - 1.856 - <div class=example> 1.857 - <p>Examples: 1.858 - 1.859 - <pre><!-- 1.860 - -->0n+5 /* represents the 5th element in the list */ 1.861 -<!-- 1.862 - -->5 /* same */</pre> 1.863 - </div> 1.864 - 1.865 - <p> When <a href="#a"><var>A</var></a> is 1 or -1, the <code>1</code> 1.866 - may be omitted from the rule. 1.867 - 1.868 - <div class=example> 1.869 - <p>Examples: 1.870 - 1.871 - <p>The following notations are therefore equivalent: 1.872 - 1.873 - <pre><!-- 1.874 - -->1n+0 /* represents all elements in the list */ 1.875 -<!-- 1.876 - -->n+0 /* same */ 1.877 -<!-- 1.878 - -->n /* same */</pre> 1.879 - </div> 1.880 - 1.881 - <p> If <a href="#b"><var>B</var></a> is 0, then every <a 1.882 - href="#a"><var>A</var></a>th element is picked. In such a case, the <a 1.883 - href="#b"><var>+B</var></a> (or <var>-B</var>) part may be omitted 1.884 - unless the <a href="#a"><var>A</var></a> part is already omitted. 1.885 - 1.886 - <div class=example> 1.887 - <p>Examples: 1.888 - 1.889 - <pre><!-- 1.890 - -->2n+0 /* represents every even element in the list */ 1.891 -<!-- 1.892 - -->2n /* same */</pre> 1.893 - </div> 1.894 - 1.895 - <p> Whitespace is permitted on either side of the ‘<code 1.896 - class=css>+</code>’ or ‘<code class=css>-</code>’ that separates 1.897 - the <var>An</var> and <a href="#b"><var>B</var></a> parts when both 1.898 - are present. 1.899 - 1.900 - <div class=example> 1.901 - <p>Valid Examples with white space: 1.902 - 1.903 - <pre><!-- 1.904 - -->3n + 1 1.905 -<!-- 1.906 - -->+3n - 2 1.907 -<!-- 1.908 - -->-n+ 6 1.909 -<!-- 1.910 - -->+6</pre> 1.911 - 1.912 - <p>Invalid Examples with white space: 1.913 - 1.914 - <pre><!-- 1.915 - -->3 n 1.916 -<!-- 1.917 - -->+ 2n 1.918 -<!-- 1.919 - -->+ 2</pre> 1.920 - </div> 1.921 - 1.922 - <h3 id=the-anb-type><span class=secno>6.2. </span> The <a 1.923 - href="#anb-production"><code><an+b></code></a> type</h3> 1.924 - 1.925 - <p> The <a href="#anb0"><var>An+B</var></a> notation was originally 1.926 - defined using a slightly different tokenizer than the rest of CSS, 1.927 - resulting in a somewhat odd definition when expressed in terms of CSS 1.928 - tokens. This section describes how to recognize the <a 1.929 - href="#anb0"><var>An+B</var></a> notation in terms of CSS tokens (thus 1.930 - defining the <a href="#anb-production"><var><an+b></var></a> type 1.931 - for CSS grammar purposes), and how to interpret the CSS tokens to 1.932 - obtain values for <a href="#a"><var>A</var></a> and <a 1.933 - href="#b"><var>B</var></a>. 1.934 - 1.935 - <p> The <a href="#anb-production"><var><an+b></var></a> type is 1.936 - defined (using the <a 1.937 - href="http://www.w3.org/TR/css3-values/#value-defs">Value Definition 1.938 - Syntax in the Values & Units spec</a>) as: 1.939 - 1.940 - <pre class=prod> 1.941 -<dfn id=anb-production><an+b></dfn> = 1.942 - odd | even | 1.943 - <a 1.944 - href="#ltinteger"><var><integer></var></a> | 1.945 - 1.946 - <a 1.947 - href="#ltn-dimension"><var><n-dimension></var></a> | 1.948 - '+'? n | 1.949 - -n | 1.950 - 1.951 - <a 1.952 - href="#ltndashdigit-dimension"><var><ndashdigit-dimension></var></a> | 1.953 - '+'? <a 1.954 - href="#ltndashdigit-ident"><var><ndashdigit-ident></var></a> | 1.955 - <a 1.956 - href="#ltdashndashdigit-ident"><var><dashndashdigit-ident></var></a> | 1.957 - 1.958 - <a 1.959 - href="#ltn-dimension"><var><n-dimension></var></a> <a 1.960 - href="#ltsigned-integer"><var><signed-integer></var></a> | 1.961 - '+'? n <a 1.962 - href="#ltsigned-integer"><var><signed-integer></var></a> | 1.963 - -n <a 1.964 - href="#ltsigned-integer"><var><signed-integer></var></a> | 1.965 - 1.966 - <a 1.967 - href="#ltn-dimension"><var><n-dimension></var></a> ['+' | '-'] <a 1.968 - href="#ltsignless-integer"><var><signless-integer></var></a> 1.969 - '+'? n ['+' | '-'] <a 1.970 - href="#ltsignless-integer"><var><signless-integer></var></a> | 1.971 - -n ['+' | '-'] <a 1.972 - href="#ltsignless-integer"><var><signless-integer></var></a></pre> 1.973 - 1.974 - <p> where: 1.975 - 1.976 - <ul> 1.977 - <li><dfn id=ltn-dimension><code><n-dimension></code></dfn> is a 1.978 - 〈dimension〉 with its type flag set to "integer", and a unit that 1.979 - is an <a href="#ascii-case-insensitive"><i>ASCII 1.980 - case-insensitive</i></a> match for "n" 1.981 - 1.982 - <li><dfn 1.983 - id=ltndashdigit-dimension><code><ndashdigit-dimension></code></dfn> 1.984 - is a 〈dimension〉 with its type flag set to "integer", and a unit 1.985 - that is an <a href="#ascii-case-insensitive"><i>ASCII 1.986 - case-insensitive</i></a> match for "n-*", where "*" is a series of 1.987 - one or more <a href="#digit"><i>digits</i></a> 1.988 - 1.989 - <li><dfn 1.990 - id=ltndashdigit-ident><code><ndashdigit-ident></code></dfn> is an 1.991 - 〈ident〉 whose representation is an <a 1.992 - href="#ascii-case-insensitive"><i>ASCII case-insensitive</i></a> 1.993 - match for "n-*", where "*" is a series of one or more <a 1.994 - href="#digit"><i>digits</i></a> 1.995 - 1.996 - <li><dfn 1.997 - id=ltdashndashdigit-ident><code><dashndashdigit-ident></code></dfn> 1.998 - is an 〈ident〉 whose representation is an <a 1.999 - href="#ascii-case-insensitive"><i>ASCII case-insensitive</i></a> 1.1000 - match for "-n-*", where "*" is a series of one or more <a 1.1001 - href="#digit"><i>digits</i></a> 1.1002 - 1.1003 - <li><dfn id=ltinteger><code><integer></code></dfn> is a 1.1004 - 〈number〉 with its type flag set to "integer" 1.1005 - 1.1006 - <li><dfn id=ltsigned-integer><code><signed-integer></code></dfn> is 1.1007 - a 〈number〉 with its type flag set to "integer", and whose 1.1008 - representation starts with "+" or "-" 1.1009 - 1.1010 - <li><dfn 1.1011 - id=ltsignless-integer><code><signless-integer></code></dfn> is a 1.1012 - 〈number〉 with its type flag set to "integer", and whose 1.1013 - representation start with a <a href="#digit"><i>digit</i></a> 1.1014 </ul> 1.1015 - 1.1016 - <p> The clauses of the production are interpreted as follows: 1.1017 - 1.1018 - <dl> 1.1019 - <dt>‘<code class=css>odd</code>’ 1.1020 - 1.1021 - <dd> <a href="#a"><var>A</var></a> is 2, <a href="#b"><var>B</var></a> 1.1022 - is 1. 1.1023 - 1.1024 - <dt>‘<code class=css>even</code>’ 1.1025 - 1.1026 - <dd> <a href="#a"><var>A</var></a> is 2, <a href="#b"><var>B</var></a> 1.1027 - is 0. 1.1028 - 1.1029 - <dt><a href="#ltinteger"><code><var><integer></var></code></a> 1.1030 - 1.1031 - <dd> <a href="#a"><var>A</var></a> is 0, <a href="#b"><var>B</var></a> 1.1032 - is the integer. 1.1033 - 1.1034 - <dt><a 1.1035 - href="#ltn-dimension"><code><var><n-dimension></var></code></a> 1.1036 - 1.1037 - <dt><code>'+'? n</code> 1.1038 - 1.1039 - <dt><code>-n</code> 1.1040 - 1.1041 - <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.1042 - respectively. <a href="#b"><var>B</var></a> is 0. 1.1043 - 1.1044 - <dt><a 1.1045 - href="#ltndashdigit-dimension"><code><var><ndashdigit-dimension></var></code></a> 1.1046 - 1.1047 - <dt><code>'+'? <a 1.1048 - href="#ltndashdigit-ident"><var><ndashdigit-ident></var></a></code> 1.1049 - 1.1050 - <dt><a 1.1051 - href="#ltdashndashdigit-ident"><code><var><dashndashdigit-ident></var></code></a> 1.1052 - 1.1053 - <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.1054 - respectively. <a href="#b"><var>B</var></a> is the dimension's unit 1.1055 - or ident's representation, as appropriate, with the first two 1.1056 - characters removed and the remainder interpreted as a base-10 number. 1.1057 - 1.1058 - <dt><code><a href="#ltn-dimension"><var><n-dimension></var></a> <a 1.1059 - href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.1060 - 1.1061 - <dt><code>'+'? n <a 1.1062 - href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.1063 - 1.1064 - <dt><code>-n <a 1.1065 - href="#ltsigned-integer"><var><signed-integer></var></a></code> 1.1066 - 1.1067 - <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.1068 - respectively. <a href="#b"><var>B</var></a> is the integer. 1.1069 - 1.1070 - <dt><code><a href="#ltn-dimension"><var><n-dimension></var></a> 1.1071 - ['+' | '-'] <a 1.1072 - href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.1073 - 1.1074 - <dt><code>'+'? n ['+' | '-'] <a 1.1075 - href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.1076 - 1.1077 - <dt><code>-n ['+' | '-'] <a 1.1078 - href="#ltsignless-integer"><var><signless-integer></var></a></code> 1.1079 - 1.1080 - <dd> <a href="#a"><var>A</var></a> is the dimension's value, 1, or -1, 1.1081 - respectively. <a href="#b"><var>B</var></a> is the integer. If a 1.1082 - ‘<code class=property>-</code>’ was provided between the two, <a 1.1083 - href="#b"><var>B</var></a> is instead the negation of the integer. 1.1084 - </dl> 1.1085 - 1.1086 - <h2 id=rule-defs><span class=secno>7. </span> Defining Grammars for 1.1087 - Rules and Other Values</h2> 1.1088 - 1.1089 - <p> The <a href="http://www.w3.org/TR/css3-values/">Values</a> spec 1.1090 - defines how to specify a grammar for properties. This section does the 1.1091 - same, but for rules. 1.1092 - 1.1093 - <p> Just like in property grammars, the notation <code><foo></code> 1.1094 - refers to the "foo" grammar term, assumed to be defined elsewhere. 1.1095 - Substituting the <code><foo></code> for its definition results in a 1.1096 - semantically identical grammar. 1.1097 - 1.1098 - <p> Several types of tokens are written literally, without quotes: 1.1099 - 1.1100 - <ul> 1.1101 - <li>〈Ident〉s (such as ‘<code class=css>auto</code>’, ‘<code 1.1102 - class=css>disc</code>’, etc.) 1.1103 - 1.1104 - <li>〈at-keyword〉s, which are written as an @ character followed by 1.1105 - the token's name, like "@media". 1.1106 - 1.1107 - <li>〈function〉s, which are written as the function name followed 1.1108 - by a ( character, like "translate(". 1.1109 - 1.1110 - <li>The 〈colon〉 (written as <code>:</code>), 〈comma〉 (written 1.1111 - as <code>,</code>), 〈semicolon〉 (written as <code>;</code>), 1.1112 - 〈(〉, 〈)〉, 〈{〉, and 〈}〉s. 1.1113 - </ul> 1.1114 - 1.1115 - <p> 〈delim〉s are written with their value enclosed in single 1.1116 - quotes. For example, a 〈delim〉 containing the "+" character is 1.1117 - written as <code>'+'</code>. Similarly, the 〈[〉 and 〈]〉s must 1.1118 - be written in single quotes, as they're used by the syntax of the 1.1119 - grammar itself to group clauses. 〈whitespace〉 is never indicated 1.1120 - in the grammar; 〈whitespace〉s are allowed before, after, and 1.1121 - between any two tokens, unless explicitly specified otherwise in prose 1.1122 - definitions. (For example, if the prelude of a rule is a selector, 1.1123 - whitespace is significant.) 1.1124 - 1.1125 - <p> When defining a function or a block, the ending token must be 1.1126 - specified in the grammar, but if it's not present in the eventual 1.1127 - token stream, it still matches. 1.1128 - 1.1129 - <div class=example> For example, the syntax of the ‘<code 1.1130 - class=css>translateX()</code>’ function is: 1.1131 - <pre>translateX( <translation-value> )</pre> 1.1132 - 1.1133 - <p> However, the stylesheet may end with the function unclosed, like: 1.1134 - 1.1135 - <pre>.foo { transform: translate(50px</pre> 1.1136 - 1.1137 - <p> The CSS parser parses this as a style rule containing one 1.1138 - declaration, whose value is a function named "translate". This 1.1139 - matches the above grammar, even though the ending token didn't appear 1.1140 - in the token stream, because by the time the parser is finished, the 1.1141 - presence of the ending token is no longer possible to determine; all 1.1142 - you have is the fact that there's a block and a function. 1.1143 - </div> 1.1144 - 1.1145 - <h3 id=declaration-rule-list><span class=secno>7.1. </span> Defining 1.1146 - Block Contents: the <a 1.1147 - href="#ltdeclaration-list"><var><declaration-list></var></a>, <a 1.1148 - href="#ltrule-list"><var><rule-list></var></a>, and <a 1.1149 - href="#ltstylesheet"><var><stylesheet></var></a> productions</h3> 1.1150 - 1.1151 - <p> The CSS parser is agnostic as to the contents of blocks, such as 1.1152 - those that come at the end of some at-rules. Defining the generic 1.1153 - grammar of the blocks in terms of tokens is non-trivial, but there are 1.1154 - dedicated and unambiguous algorithms defined for parsing this. 1.1155 - 1.1156 - <p> The <dfn 1.1157 - id=ltdeclaration-list><var><declaration-list></var></dfn> 1.1158 - production represents a list of declarations. It may only be used in 1.1159 - grammars as the sole value in a block, and represents that the 1.1160 - contents of the block must be parsed using the <a 1.1161 - href="#consume-a-list-of-declarations0"><i>consume a list of 1.1162 - declarations</i></a> algorithm. 1.1163 - 1.1164 - <p> Similarly, the <dfn id=ltrule-list><var><rule-list></var></dfn> 1.1165 - production represents a list of rules, and may only be used in 1.1166 - grammars as the sole value in a block. It represents that the contents 1.1167 - of the block must be parsed using the <a 1.1168 - href="#consume-a-list-of-rules0"><i>consume a list of rules</i></a> 1.1169 - algorithm. 1.1170 - 1.1171 - <p> Finally, the <dfn id=ltstylesheet><var><stylesheet></var></dfn> 1.1172 - production represents a list of rules. It is identical to <a 1.1173 - href="#ltrule-list"><var><rule-list></var></a>, except that blocks 1.1174 - using it default to accepting all rules that aren't otherwise limited 1.1175 - to a particular context. 1.1176 - 1.1177 - <div class=example> For example, the ‘<code 1.1178 - class=css>@font-face</code>’ rule is defined to have an empty 1.1179 - prelude, and to contain a list of declarations. This is expressed with 1.1180 - the following grammar: 1.1181 - <pre>@font-face { <declaration-list> }</pre> 1.1182 - 1.1183 - <p> This is a complete and sufficient definition of the rule's 1.1184 - grammar. 1.1185 - 1.1186 - <p> For another example, ‘<code class=css>@keyframes</code>’ rules 1.1187 - are more complex, interpreting their prelude as a name and containing 1.1188 - keyframes rules in their block Their grammar is: 1.1189 - 1.1190 - <pre>@keyframes <keyframes-name> { <rule-list> }</pre> 1.1191 - </div> 1.1192 - 1.1193 - <p> For rules that use <a 1.1194 - href="#ltdeclaration-list"><var><declaration-list></var></a>, the 1.1195 - spec for the rule must define which properties, descriptors, and/or 1.1196 - at-rules are valid inside the rule; this may be as simple as saying 1.1197 - "The @foo rule accepts the properties/descriptors defined in this 1.1198 - specification/section.", and extension specs may simply say "The @foo 1.1199 - rule additionally accepts the following properties/descriptors.". Any 1.1200 - declarations or at-rules found inside the block that are not defined 1.1201 - as valid must be removed from the rule's value. 1.1202 - 1.1203 - <p> Within a <a 1.1204 - href="#ltdeclaration-list"><var><declaration-list></var></a>, 1.1205 - <code>!important</code> is automatically invalid on any descriptors. 1.1206 - If the rule accepts properties, the spec for the rule must define 1.1207 - whether the properties interact with the cascade, and with what 1.1208 - specificity. If they don't interact with the cascade, properties 1.1209 - containing <code>!important</code> are automatically invalid; 1.1210 - otherwise using <code>!important</code> is valid and has its usual 1.1211 - effect on the cascade origin of the property. 1.1212 - 1.1213 - <div class=example> For example, the grammar for ‘<code 1.1214 - class=css>@font-face</code>’ in the previous example must, in 1.1215 - addition to what is written there, define that the allowed 1.1216 - declarations are the descriptors defined in the Fonts spec.</div> 1.1217 - 1.1218 - <p> For rules that use <a 1.1219 - href="#ltrule-list"><var><rule-list></var></a>, the spec for the 1.1220 - rule must define what types of rules are valid inside the rule, same 1.1221 - as <a href="#ltdeclaration-list"><var><declaration-list></var></a>, 1.1222 - and unrecognized rules must similarly be removed from the rule's 1.1223 - value. 1.1224 - 1.1225 - <div class=example> For example, the grammar for ‘<code 1.1226 - class=css>@keyframes</code>’ in the previous example must, in 1.1227 - addition to what is written there, define that the only allowed rules 1.1228 - are <var><keyframe-rule></var>s, which are defined as: 1.1229 - <pre><keyframe-rule> = <keyframe-selector> { <declaration-list> }</pre> 1.1230 - 1.1231 - <p> Keyframe rules, then, must further define that they accept as 1.1232 - declarations all animatable CSS properties, plus the ‘<code 1.1233 - class=property>animation-timing-function</code>’ property, but that 1.1234 - they do not interact with the cascade. 1.1235 - </div> 1.1236 - 1.1237 - <p> For rules that use <a 1.1238 - href="#ltstylesheet"><var><stylesheet></var></a>, all rules are 1.1239 - allowed by default, but the spec for the rule may define what types of 1.1240 - rules are <em>invalid</em> inside the rule. 1.1241 - 1.1242 - <div class=example> For example, the ‘<code 1.1243 - class=css>@media</code>’ rule accepts anything that can be placed in 1.1244 - a stylesheet, except more ‘<code class=css>@media</code>’ rules. 1.1245 - As such, its grammar is: 1.1246 - <pre>@media <media-query-list> { <stylesheet> }</pre> 1.1247 - 1.1248 - <p> It additionally defines a restriction that the <a 1.1249 - href="#ltstylesheet"><var><stylesheet></var></a> can not contain 1.1250 - ‘<code class=css>@media</code>’ rules, which causes them to be 1.1251 - dropped from the outer rule's value if they appear. 1.1252 - </div> 1.1253 - 1.1254 - <h2 id=serialization><span class=secno>8. </span>Serialization</h2> 1.1255 - 1.1256 - <p> This specification does not define how to serialize CSS in general, 1.1257 - leaving that task to the CSSOM and individual feature specifications. 1.1258 - However, there is one important facet that must be specified here 1.1259 - regarding comments, to ensure accurate "round-tripping" of data from 1.1260 - text to CSS objects and back. 1.1261 - 1.1262 - <p> The tokenizer described in this specification does not produce 1.1263 - tokens for comments, or otherwise preserve them in any way. 1.1264 - Implementations may preserve the contents of comments and their 1.1265 - location in the token stream. If they do, this preserved information 1.1266 - must have no effect on the parsing step, but must be serialized in its 1.1267 - position as "/*" followed by its contents followed by "*/". 1.1268 - 1.1269 - <p> If the implementation does not preserve comments, it must insert 1.1270 - the text "/**/" between the serialization of adjacent tokens when the 1.1271 - two tokens are of the following pairs: 1.1272 - 1.1273 - <ul> 1.1274 - <li> a 〈hash〉 or 〈at-keyword〉 followed by a 〈number〉, 1.1275 - 〈percentage〉, 〈ident〉, 〈dimension〉, 〈unicode-range〉, 1.1276 - 〈url〉, or a 〈function〉 token; 1.1277 - 1.1278 - <li> 〈number〉s, 〈ident〉s, and 〈dimension〉s in any 1.1279 - combination; 1.1280 - 1.1281 - <li> a 〈number〉, 〈ident〉, or 〈dimension〉 followed by a 1.1282 - 〈percentage〉, 〈unicode-range〉, 〈url〉, or 〈function〉; 1.1283 - 1.1284 - <li> an 〈ident〉 followed by a 〈(〉; 1.1285 - 1.1286 - <li> a 〈delim〉 containing "#" or "@" followed by any token except 1.1287 - 〈whitespace〉; 1.1288 - 1.1289 - <li> a 〈delim〉 containing "-", "+", ".", "<", ">", or "!" 1.1290 - following or followed by any token except 〈whitespace〉; 1.1291 - 1.1292 - <li> a 〈delim〉 containing "/" following or followed by a 1.1293 - 〈delim〉 containing "*". 1.1294 - </ul> 1.1295 - 1.1296 - <p class=note> The preceding pairs of tokens can only be adjacent due 1.1297 - to comments in the original text, so the above rule reinserts the 1.1298 - minimum number of comments into the serialized text to ensure an 1.1299 - accurate round-trip. (Roughly. The 〈delim〉 rules are slightly too 1.1300 - powerful, for simplicity.) 1.1301 - 1.1302 - <h3 id=serializing-anb><span class=secno>8.1. </span> Serializing <a 1.1303 - href="#anb-production"><var><an+b></var></a></h3> 1.1304 - 1.1305 - <p> To serialize an <a href="#anb-production"><var><an+b></var></a> 1.1306 - value, let <var>s</var> initially be the empty string: 1.1307 - 1.1308 - <dl> 1.1309 - <dt><a href="#a"><var>A</var></a> and <a href="#b"><var>B</var></a> 1.1310 - are both zero 1.1311 - 1.1312 - <dd> Append "0" to <var>s</var>. 1.1313 - 1.1314 - <dt><a href="#a"><var>A</var></a> is zero, <a 1.1315 - href="#b"><var>B</var></a> is non-zero 1.1316 - 1.1317 - <dd> Serialize <a href="#b"><var>B</var></a> and append it to 1.1318 - <var>s</var>. 1.1319 - 1.1320 - <dt><a href="#a"><var>A</var></a> is non-zero, <a 1.1321 - href="#b"><var>B</var></a> is zero 1.1322 - 1.1323 - <dd> Serialize <a href="#a"><var>A</var></a> and append it to 1.1324 - <var>s</var>. Append "n" to <var>s</var>. 1.1325 - 1.1326 - <dt><a href="#a"><var>A</var></a> and <a href="#b"><var>B</var></a> 1.1327 - are both non-zero 1.1328 - 1.1329 - <dd> Serialize <a href="#a"><var>A</var></a> and append it to 1.1330 - <var>s</var>. Append "n" to <var>s</var>. If <a 1.1331 - href="#b"><var>B</var></a> is positive, append "+" to <var>s</var> 1.1332 - Serialize <a href="#b"><var>B</var></a> and append it to 1.1333 - <var>s</var>. 1.1334 - </dl> 1.1335 - 1.1336 - <p> Return <var>s</var>. <!-- 1.1337 + <!-- 1.1338 1.1339 TTTTTTTTTTTTTTTTTTTTTTTHHHHHHHHH HHHHHHHHHEEEEEEEEEEEEEEEEEEEEEE 1.1340 T:::::::::::::::::::::TH:::::::H H:::::::HE::::::::::::::::::::E 1.1341 @@ -4026,9 +4075,9 @@ 1.1342 EEEEEEEEEEEEEEEEEEEEEENNNNNNNN NNNNNNNDDDDDDDDDDDDD 1.1343 --> 1.1344 1.1345 - <h2 id=conformance><span class=secno>9. </span> Conformance</h2> 1.1346 - 1.1347 - <h3 id=conventions><span class=secno>9.1. </span> Document conventions</h3> 1.1348 + <h2 id=conformance><span class=secno>10. </span> Conformance</h2> 1.1349 + 1.1350 + <h3 id=conventions><span class=secno>10.1. </span> Document conventions</h3> 1.1351 1.1352 <p>Conformance requirements are expressed with a combination of 1.1353 descriptive assertions and RFC 2119 terminology. The key words 1.1354 @@ -4055,7 +4104,7 @@ 1.1355 1.1356 <p class=note>Note, this is an informative note. 1.1357 1.1358 - <h3 id=conformance-classes><span class=secno>9.2. </span> Conformance 1.1359 + <h3 id=conformance-classes><span class=secno>10.2. </span> Conformance 1.1360 classes</h3> 1.1361 1.1362 <p>Conformance to CSS Syntax Module Level 3 is defined for three 1.1363 @@ -4157,7 +4206,7 @@ 1.1364 title="section 2."><strong>2.</strong></a> 1.1365 1.1366 <li>authoring tool, <a href="#authoring-tool" 1.1367 - title="section 9.2."><strong>9.2.</strong></a> 1.1368 + title="section 10.2."><strong>10.2.</strong></a> 1.1369 1.1370 <li>B, <a href="#b" title="section 6."><strong>6.</strong></a> 1.1371 1.1372 @@ -4361,7 +4410,7 @@ 1.1373 title="section 5.2."><strong>5.2.</strong></a> 1.1374 1.1375 <li>renderer, <a href="#renderer" 1.1376 - title="section 9.2."><strong>9.2.</strong></a> 1.1377 + title="section 10.2."><strong>10.2.</strong></a> 1.1378 1.1379 <li><var><rule-list></var>, <a href="#ltrule-list" 1.1380 title="section 7.1."><strong>7.1.</strong></a> 1.1381 @@ -4408,7 +4457,7 @@ 1.1382 <li>style sheet 1.1383 <ul> 1.1384 <li>as conformance class, <a href="#style-sheet" 1.1385 - title="section 9.2."><strong>9.2.</strong></a> 1.1386 + title="section 10.2."><strong>10.2.</strong></a> 1.1387 </ul> 1.1388 1.1389 <li>uppercase letter, <a href="#uppercase-letter"
2.1 --- a/css-syntax/Overview.src.html Fri May 31 13:52:41 2013 -0700 2.2 +++ b/css-syntax/Overview.src.html Mon Jun 03 15:59:38 2013 +0900 2.3 @@ -1671,54 +1671,6 @@ 2.4 and the character whose codepoint is the <i>end of the range</i>. 2.5 2.6 2.7 -<h3> 2.8 -Changes from CSS 2.1 Tokenizer</h3> 2.9 - 2.10 - <p> 2.11 - <em>This section is non-normative.</em> 2.12 - 2.13 - <p class='note'> 2.14 - Note that the point of this spec is to match reality; 2.15 - changes from CSS2.1’s tokenizer are nearly always because the tokenizer specified something that doesn't match actual browser behavior, 2.16 - or left something unspecified. 2.17 - If some detail doesn't match browsers, 2.18 - please let me know 2.19 - as it's almost certainly unintentional. 2.20 - 2.21 - <ol> 2.22 - <li> 2.23 - The 〈prefix-match〉, 〈suffix-match〉, and 〈substring-match〉 tokens have been imported from Selectors 3. 2.24 - 2.25 - <li> 2.26 - The BAD-URI token (now 〈bad-url〉) is "self-contained". 2.27 - In other words, once the tokenizer realizes it's in a 〈bad-url〉 rather than a 〈url〉, 2.28 - it just seeks forward to look for the closing ), 2.29 - ignoring everything else. 2.30 - This behavior is simpler than treating it like a 〈function〉 2.31 - and paying attention to opened blocks and such. 2.32 - Only WebKit exhibits this behavior, 2.33 - but it doesn't appear that we've gotten any compat bugs from it. 2.34 - 2.35 - <li> 2.36 - The 〈comma〉 has been added. 2.37 - 2.38 - <li> 2.39 - The 〈number〉, 〈number〉, and 〈dimension〉 tokens have been changed 2.40 - to include the preceding +/- sign as part of their value 2.41 - (rather than as a separate 〈delim〉 that needs to be manually handled every time the token is mentioned in other specs). 2.42 - The only consequence of this is that comments can no longer be inserted between the sign and the number. 2.43 - 2.44 - <li> 2.45 - Scientific notation is supported for numbers/percentages/dimensions to match SVG, 2.46 - per WG resolution. 2.47 - 2.48 - <li> 2.49 - 〈column〉 has been added, 2.50 - to keep Selectors parsing in single-token lookahead. 2.51 - 2.52 - </ol> 2.53 - 2.54 - 2.55 <!-- 2.56 PPPPPPPPPPPPPPPPP AAA RRRRRRRRRRRRRRRRR SSSSSSSSSSSSSSS EEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRR 2.57 P::::::::::::::::P A:::A R::::::::::::::::R SS:::::::::::::::SE::::::::::::::::::::ER::::::::::::::::R 2.58 @@ -2396,61 +2348,6 @@ 2.59 2.60 2.61 2.62 -<h3> 2.63 -Changes from CSS 2.1 Core Grammar</h3> 2.64 - 2.65 - <p> 2.66 - <em>This section is non-normative.</em> 2.67 - 2.68 - <p class='note'> 2.69 - Note that the point of this spec is to match reality; 2.70 - changes from CSS2.1’s Core Grammar are nearly always because the Core Grammar specified something that doesn't match actual browser behavior, 2.71 - or left something unspecified. 2.72 - If some detail doesn't match browsers, 2.73 - please let me know 2.74 - as it's almost certainly unintentional. 2.75 - 2.76 - <ol> 2.77 - <li> 2.78 - The handling of some miscellanous "special" tokens 2.79 - (like an unmatched 〈}〉) 2.80 - showing up in various places in the grammar 2.81 - has been specified with some reasonable behavior shown by at least one browser. 2.82 - Previously, stylesheets with those tokens in those places just didn't match the stylesheet grammar at all, 2.83 - so their handling was totally undefined. 2.84 - Specifically: 2.85 - 2.86 - <ul> 2.87 - <li> 2.88 - [] blocks, () blocks and functions can now contain {} blocks, 〈at-keyword〉s or 〈semicolon〉s 2.89 - 2.90 - <li> 2.91 - Selectors can now contain semicolons 2.92 - 2.93 - <li> 2.94 - Selectors and at-rule preludes can now contain 〈at-keyword〉s 2.95 - </ul> 2.96 - 2.97 - <li> 2.98 - The <var>An+B</var> microsyntax has now been formally defined in terms of CSS tokens, 2.99 - rather than with a separate tokenizer. 2.100 - This has resulted in minor differences: 2.101 - 2.102 - <ul> 2.103 - <li> 2.104 - In values starting with "+n", 2.105 - a space is now allowed between the "+" and "n". 2.106 - (This is an accidental consequence of the "+" and "n" parsing as separate CSS tokens, 2.107 - and CSS's value grammar ignoring whitespace.) 2.108 - 2.109 - <li> 2.110 - In some cases, "-" characters or digits can be escaped 2.111 - (when they appear as part of the unit of a 〈dimension〉 or 〈ident〉). 2.112 - </ul> 2.113 - </ol> 2.114 - 2.115 - 2.116 - 2.117 <h2 id="anb"> 2.118 The <var>An+B</var> microsyntax</h2> 2.119 2.120 @@ -2912,7 +2809,162 @@ 2.121 <p> 2.122 Return <var>s</var>. 2.123 2.124 - 2.125 +<h2 id="changes">Changes from CSS 2.1 and Selectors Level 3</h2> 2.126 + 2.127 + <p> 2.128 + <em>This section is non-normative.</em> 2.129 + 2.130 + <p class='note'> 2.131 + Note that the point of this spec is to match reality; 2.132 + changes from CSS2.1 are nearly always because CSS 2.1 specified something that doesn't match actual browser behavior, 2.133 + or left something unspecified. 2.134 + If some detail doesn't match browsers, 2.135 + please let me know 2.136 + as it's almost certainly unintentional. 2.137 + 2.138 + <p> 2.139 + Changes in decoding from a byte stream: 2.140 + 2.141 + <ul> 2.142 + <li> 2.143 + Only detect ''@charset'' rules in ASCII-compatible byte patterns. 2.144 + 2.145 + <li> 2.146 + Ignore ''@charset'' rules that specify an ASCII-incompatible encoding, 2.147 + as that would cause the rule itself to not decode properly. 2.148 + 2.149 + <li> 2.150 + Refer to the the <a href="http://encoding.spec.whatwg.org/">Encoding Standard</a> 2.151 + rather than the IANA registery for character encodings. 2.152 + 2.153 + </ul> 2.154 + 2.155 + <p> 2.156 + Tokenization changes: 2.157 + 2.158 + <ul> 2.159 + <li> 2.160 + Any U+0000 NULL character in the CSS source is replaced with U+FFFD REPLACEMENT CHARACTER. 2.161 + 2.162 + <li> 2.163 + Any hexadecimal escape sequence such as ''\0'' that evaluate to zero 2.164 + produce U+FFFD REPLACEMENT CHARACTER rather than U+0000 NULL. 2.165 + <!-- 2.166 + This covers a security issue: 2.167 + https://bugzilla.mozilla.org/show_bug.cgi?id=228856 2.168 + --> 2.169 + 2.170 + <li> 2.171 + The definition of <i>non-ASCII character</i> was changed 2.172 + to be consistent with every definition of ASCII. 2.173 + This affects characters U+0080 to U+009F, 2.174 + which are now <i>name characters</i> rather than 〈delim〉s, 2.175 + like the rest of <i>non-ASCII characters</i>. 2.176 + 2.177 + <li> 2.178 + Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore. 2.179 + BAD_COMMENT is now considered the same as normal token (not an error.) 2.180 + <a href="#serialization">Serialization</a> is responsible 2.181 + for inserting comments as necessary between tokens that need to be separated, 2.182 + e.g. two consecutive 〈ident〉s. 2.183 + 2.184 + <li> 2.185 + The 〈unicode-range〉 token is now more restrictive. 2.186 + <span class="issue">Should it? I can’t find a case where this change is even testable.</span> 2.187 + <span class="issue">Align the definition with the Fonts spec.</span> 2.188 + 2.189 + <li> 2.190 + Apply the <a href="http://www.w3.org/TR/CSS21/syndata.html#unexpected-eof">EOF error handling rule</a> in the tokenizer 2.191 + and emit normal 〈string〉 and 〈url〉 tokens rather than BAD_STRING or BAD_URI 2.192 + on EOF. 2.193 + 2.194 + <li> 2.195 + The 〈prefix-match〉, 〈suffix-match〉, and 〈substring-match〉 tokens have been imported from Selectors 3. 2.196 + 2.197 + <li> 2.198 + The BAD_URI token (now 〈bad-url〉) is "self-contained". 2.199 + In other words, once the tokenizer realizes it's in a 〈bad-url〉 rather than a 〈url〉, 2.200 + it just seeks forward to look for the closing ), 2.201 + ignoring everything else. 2.202 + This behavior is simpler than treating it like a 〈function〉 2.203 + and paying attention to opened blocks and such. 2.204 + Only WebKit exhibits this behavior, 2.205 + but it doesn't appear that we've gotten any compat bugs from it. 2.206 + 2.207 + <li> 2.208 + The 〈comma〉 has been added. 2.209 + 2.210 + <li> 2.211 + The 〈number〉, 〈number〉, and 〈dimension〉 tokens have been changed 2.212 + to include the preceding +/- sign as part of their value 2.213 + (rather than as a separate 〈delim〉 that needs to be manually handled every time the token is mentioned in other specs). 2.214 + The only consequence of this is that comments can no longer be inserted between the sign and the number. 2.215 + 2.216 + <li> 2.217 + Scientific notation is supported for numbers/percentages/dimensions to match SVG, 2.218 + per WG resolution. 2.219 + 2.220 + <li> 2.221 + 〈column〉 has been added, 2.222 + to keep Selectors parsing in single-token lookahead. 2.223 + 2.224 + </ul> 2.225 + 2.226 + <p> 2.227 + Parsing changes: 2.228 + 2.229 + <ul> 2.230 + <li> 2.231 + Any list of declaration now also accepts at-rules, like ''@page'', 2.232 + per WG resolution. 2.233 + This makes a difference in error handling 2.234 + even if no such at-rules are defined yet: 2.235 + an at-rule, valid or not, ends and lets the next declaration being 2.236 + at a {} block without a 〈semicolon〉. 2.237 + 2.238 + <li> 2.239 + The handling of some miscellanous "special" tokens 2.240 + (like an unmatched 〈}〉) 2.241 + showing up in various places in the grammar 2.242 + has been specified with some reasonable behavior shown by at least one browser. 2.243 + Previously, stylesheets with those tokens in those places just didn't match the stylesheet grammar at all, 2.244 + so their handling was totally undefined. 2.245 + Specifically: 2.246 + 2.247 + <ul> 2.248 + <li> 2.249 + [] blocks, () blocks and functions can now contain {} blocks, 〈at-keyword〉s or 〈semicolon〉s 2.250 + 2.251 + <li> 2.252 + Selectors can now contain semicolons 2.253 + 2.254 + <li> 2.255 + Selectors and at-rule preludes can now contain 〈at-keyword〉s 2.256 + </ul> 2.257 + 2.258 + </ul> 2.259 + 2.260 + <p> 2.261 + <var>An+B</var> changes from Selectors Level 3 [[SELECT]]: 2.262 + 2.263 + <ul> 2.264 + <li> 2.265 + The <var>An+B</var> microsyntax has now been formally defined in terms of CSS tokens, 2.266 + rather than with a separate tokenizer. 2.267 + This has resulted in minor differences: 2.268 + 2.269 + <ul> 2.270 + <li> 2.271 + In values starting with "+n", 2.272 + a space is now allowed between the "+" and "n". 2.273 + (This is an accidental consequence of the "+" and "n" parsing as separate CSS tokens, 2.274 + and CSS's value grammar ignoring whitespace.) 2.275 + 2.276 + <li> 2.277 + In some cases, "-" characters or digits can be escaped 2.278 + (when they appear as part of the unit of a 〈dimension〉 or 〈ident〉). 2.279 + </ul> 2.280 + </ul> 2.281 2.282 2.283
