Skip to content

Commit 901b99c

Browse files
SimonSapinSimonSapin
committed
[css-syntax] Merge and update the Changes sections.
1 parent e728ab3 commit 901b99c

2 files changed

Lines changed: 306 additions & 205 deletions

File tree

‎css-syntax/Overview.html‎

Lines changed: 151 additions & 102 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@
1111

1212
<meta content="CSS Syntax Module Level 3 (CSS3 Syntax)" name=dcterms.title>
1313
<meta content=text name=dcterms.type>
14-
<meta content=2013-05-31 name=dcterms.date>
14+
<meta content=2013-06-03 name=dcterms.date>
1515
<meta content="Tab Atkins Jr." name=dcterms.creator>
1616
<meta content=W3C name=dcterms.publisher>
1717
<meta content="http://dev.w3.org/csswg/css3-syntax/"
@@ -32,7 +32,7 @@
3232
<h1 class=p-name>CSS Syntax Module Level 3</h1>
3333

3434
<h2 class="no-num no-toc" id=longstatus-date>Editor's Draft <time
35-
class=dt-updated datetime=20130531>31 May 2013</time></h2>
35+
class=dt-updated datetime=20130603> 3 June 2013</time></h2>
3636

3737
<dl>
3838
<dt>This version:
@@ -234,9 +234,6 @@ <h2 class="no-num no-toc" id=contents> Table of contents</h2>
234234
<li><a href="#set-the-unicode-ranges-range"><span class=secno>4.3.15.
235235
</span> Set the 〈unicode-range〉’s range</a>
236236
</ul>
237-
238-
<li><a href="#changes-from-css-2.1-tokenizer"><span class=secno>4.4.
239-
</span> Changes from CSS 2.1 Tokenizer</a>
240237
</ul>
241238

242239
<li><a href="#parsing"><span class=secno>5. </span> Parsing</a>
@@ -293,9 +290,6 @@ <h2 class="no-num no-toc" id=contents> Table of contents</h2>
293290
<li><a href="#consume-a-function"><span class=secno>5.4.8. </span>
294291
Consume a function</a>
295292
</ul>
296-
297-
<li><a href="#changes-from-css-2.1-core-grammar"><span class=secno>5.5.
298-
</span> Changes from CSS 2.1 Core Grammar</a>
299293
</ul>
300294

301295
<li><a href="#anb"><span class=secno>6. </span> The <var>An+B</var>
@@ -324,12 +318,15 @@ <h2 class="no-num no-toc" id=contents> Table of contents</h2>
324318
Serializing <var>&lt;an+b></var></a>
325319
</ul>
326320

327-
<li><a href="#conformance"><span class=secno>9. </span> Conformance</a>
321+
<li><a href="#changes"><span class=secno>9. </span>Changes from CSS 2.1
322+
and Selectors Level 3</a>
323+
324+
<li><a href="#conformance"><span class=secno>10. </span> Conformance</a>
328325
<ul class=toc>
329-
<li><a href="#conventions"><span class=secno>9.1. </span> Document
326+
<li><a href="#conventions"><span class=secno>10.1. </span> Document
330327
conventions</a>
331328

332-
<li><a href="#conformance-classes"><span class=secno>9.2. </span>
329+
<li><a href="#conformance-classes"><span class=secno>10.2. </span>
333330
Conformance classes</a>
334331
</ul>
335332

@@ -2375,47 +2372,7 @@ <h4 id=set-the-unicode-ranges-range><span class=secno>4.3.15. </span>
23752372
between the character whose codepoint is the <a
23762373
href="#start-of-the-range"><i>start of the range</i></a> and the
23772374
character whose codepoint is the <a href="#end-of-the-range"><i>end of
2378-
the range</i></a>.
2379-
2380-
<h3 id=changes-from-css-2.1-tokenizer><span class=secno>4.4. </span>
2381-
Changes from CSS 2.1 Tokenizer</h3>
2382-
2383-
<p> <em>This section is non-normative.</em>
2384-
2385-
<p class=note> Note that the point of this spec is to match reality;
2386-
changes from CSS2.1’s tokenizer are nearly always because the
2387-
tokenizer specified something that doesn't match actual browser
2388-
behavior, or left something unspecified. If some detail doesn't match
2389-
browsers, please let me know as it's almost certainly unintentional.
2390-
2391-
<ol>
2392-
<li> The 〈prefix-match〉, 〈suffix-match〉, and
2393-
〈substring-match〉 tokens have been imported from Selectors 3.
2394-
2395-
<li> The BAD-URI token (now 〈bad-url〉) is "self-contained". In
2396-
other words, once the tokenizer realizes it's in a 〈bad-url〉
2397-
rather than a 〈url〉, it just seeks forward to look for the
2398-
closing ), ignoring everything else. This behavior is simpler than
2399-
treating it like a 〈function〉 and paying attention to opened
2400-
blocks and such. Only WebKit exhibits this behavior, but it doesn't
2401-
appear that we've gotten any compat bugs from it.
2402-
2403-
<li> The 〈comma〉 has been added.
2404-
2405-
<li> The 〈number〉, 〈number〉, and 〈dimension〉 tokens have
2406-
been changed to include the preceding +/- sign as part of their value
2407-
(rather than as a separate 〈delim〉 that needs to be manually
2408-
handled every time the token is mentioned in other specs). The only
2409-
consequence of this is that comments can no longer be inserted
2410-
between the sign and the number.
2411-
2412-
<li> Scientific notation is supported for
2413-
numbers/percentages/dimensions to match SVG, per WG resolution.
2414-
2415-
<li> 〈column〉 has been added, to keep Selectors parsing in
2416-
single-token lookahead.
2417-
</ol>
2418-
<!--
2375+
the range</i></a>. <!--
24192376
PPPPPPPPPPPPPPPPP AAA RRRRRRRRRRRRRRRRR SSSSSSSSSSSSSSS EEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRR
24202377
P::::::::::::::::P A:::A R::::::::::::::::R SS:::::::::::::::SE::::::::::::::::::::ER::::::::::::::::R
24212378
P::::::PPPPPP:::::P A:::::A R::::::RRRRRR:::::R S:::::SSSSSS::::::SE::::::::::::::::::::ER::::::RRRRRR:::::R
@@ -3398,49 +3355,6 @@ <h4 id=consume-a-function><span class=secno>5.4.8. </span> <dfn
33983355
value</i></a> and append the returned value to the function's value.
33993356
</dl>
34003357

3401-
<h3 id=changes-from-css-2.1-core-grammar><span class=secno>5.5. </span>
3402-
Changes from CSS 2.1 Core Grammar</h3>
3403-
3404-
<p> <em>This section is non-normative.</em>
3405-
3406-
<p class=note> Note that the point of this spec is to match reality;
3407-
changes from CSS2.1’s Core Grammar are nearly always because the
3408-
Core Grammar specified something that doesn't match actual browser
3409-
behavior, or left something unspecified. If some detail doesn't match
3410-
browsers, please let me know as it's almost certainly unintentional.
3411-
3412-
<ol>
3413-
<li> The handling of some miscellanous "special" tokens (like an
3414-
unmatched 〈}〉) showing up in various places in the grammar has
3415-
been specified with some reasonable behavior shown by at least one
3416-
browser. Previously, stylesheets with those tokens in those places
3417-
just didn't match the stylesheet grammar at all, so their handling
3418-
was totally undefined. Specifically:
3419-
<ul>
3420-
<li> [] blocks, () blocks and functions can now contain {} blocks,
3421-
〈at-keyword〉s or 〈semicolon〉s
3422-
3423-
<li> Selectors can now contain semicolons
3424-
3425-
<li> Selectors and at-rule preludes can now contain
3426-
〈at-keyword〉s
3427-
</ul>
3428-
3429-
<li> The <a href="#anb0"><var>An+B</var></a> microsyntax has now been
3430-
formally defined in terms of CSS tokens, rather than with a separate
3431-
tokenizer. This has resulted in minor differences:
3432-
<ul>
3433-
<li> In values starting with "+n", a space is now allowed between
3434-
the "+" and "n". (This is an accidental consequence of the "+" and
3435-
"n" parsing as separate CSS tokens, and CSS's value grammar
3436-
ignoring whitespace.)
3437-
3438-
<li> In some cases, "-" characters or digits can be escaped (when
3439-
they appear as part of the unit of a 〈dimension〉 or
3440-
〈ident〉).
3441-
</ul>
3442-
</ol>
3443-
34443358
<h2 id=anb><span class=secno>6. </span> The <a
34453359
href="#anb0"><var>An+B</var></a> microsyntax</h2>
34463360

@@ -3987,7 +3901,142 @@ <h3 id=serializing-anb><span class=secno>8.1. </span> Serializing <a
39873901
<var>s</var>.
39883902
</dl>
39893903

3990-
<p> Return <var>s</var>. <!--
3904+
<p> Return <var>s</var>.
3905+
3906+
<h2 id=changes><span class=secno>9. </span>Changes from CSS 2.1 and
3907+
Selectors Level 3</h2>
3908+
3909+
<p> <em>This section is non-normative.</em>
3910+
3911+
<p class=note> Note that the point of this spec is to match reality;
3912+
changes from CSS2.1 are nearly always because CSS 2.1 specified
3913+
something that doesn't match actual browser behavior, or left
3914+
something unspecified. If some detail doesn't match browsers, please
3915+
let me know as it's almost certainly unintentional.
3916+
3917+
<p> Changes in decoding from a byte stream:
3918+
3919+
<ul>
3920+
<li> Only detect ‘<code class=css>@charset</code>’ rules in
3921+
ASCII-compatible byte patterns.
3922+
3923+
<li> Ignore ‘<code class=css>@charset</code>’ rules that specify
3924+
an ASCII-incompatible encoding, as that would cause the rule itself
3925+
to not decode properly.
3926+
3927+
<li> Refer to the the <a
3928+
href="http://encoding.spec.whatwg.org/">Encoding Standard</a> rather
3929+
than the IANA registery for character encodings.
3930+
</ul>
3931+
3932+
<p> Tokenization changes:
3933+
3934+
<ul>
3935+
<li> Any U+0000 NULL character in the CSS source is replaced with
3936+
U+FFFD REPLACEMENT CHARACTER.
3937+
3938+
<li> Any hexadecimal escape sequence such as ‘<code
3939+
class=css>\0</code>’ that evaluate to zero produce U+FFFD
3940+
REPLACEMENT CHARACTER rather than U+0000 NULL. <!--
3941+
This covers a security issue:
3942+
https://bugzilla.mozilla.org/show_bug.cgi?id=228856
3943+
-->
3944+
3945+
<li> The definition of <a href="#non-ascii-character"><i>non-ASCII
3946+
character</i></a> was changed to be consistent with every definition
3947+
of ASCII. This affects characters U+0080 to U+009F, which are now <a
3948+
href="#name-character"><i>name characters</i></a> rather than
3949+
〈delim〉s, like the rest of <a
3950+
href="#non-ascii-character"><i>non-ASCII characters</i></a>.
3951+
3952+
<li> Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore.
3953+
BAD_COMMENT is now considered the same as normal token (not an
3954+
error.) <a href="#serialization">Serialization</a> is responsible for
3955+
inserting comments as necessary between tokens that need to be
3956+
separated, e.g. two consecutive 〈ident〉s.
3957+
3958+
<li> The 〈unicode-range〉 token is now more restrictive. <span
3959+
class=issue>Should it? I can’t find a case where this change is
3960+
even testable.</span> <span class=issue>Align the definition with the
3961+
Fonts spec.</span>
3962+
3963+
<li> Apply the <a
3964+
href="http://www.w3.org/TR/CSS21/syndata.html#unexpected-eof">EOF
3965+
error handling rule</a> in the tokenizer and emit normal 〈string〉
3966+
and 〈url〉 tokens rather than BAD_STRING or BAD_URI on EOF.
3967+
3968+
<li> The 〈prefix-match〉, 〈suffix-match〉, and
3969+
〈substring-match〉 tokens have been imported from Selectors 3.
3970+
3971+
<li> The BAD_URI token (now 〈bad-url〉) is "self-contained". In
3972+
other words, once the tokenizer realizes it's in a 〈bad-url〉
3973+
rather than a 〈url〉, it just seeks forward to look for the
3974+
closing ), ignoring everything else. This behavior is simpler than
3975+
treating it like a 〈function〉 and paying attention to opened
3976+
blocks and such. Only WebKit exhibits this behavior, but it doesn't
3977+
appear that we've gotten any compat bugs from it.
3978+
3979+
<li> The 〈comma〉 has been added.
3980+
3981+
<li> The 〈number〉, 〈number〉, and 〈dimension〉 tokens have
3982+
been changed to include the preceding +/- sign as part of their value
3983+
(rather than as a separate 〈delim〉 that needs to be manually
3984+
handled every time the token is mentioned in other specs). The only
3985+
consequence of this is that comments can no longer be inserted
3986+
between the sign and the number.
3987+
3988+
<li> Scientific notation is supported for
3989+
numbers/percentages/dimensions to match SVG, per WG resolution.
3990+
3991+
<li> 〈column〉 has been added, to keep Selectors parsing in
3992+
single-token lookahead.
3993+
</ul>
3994+
3995+
<p> Parsing changes:
3996+
3997+
<ul>
3998+
<li> Any list of declaration now also accepts at-rules, like ‘<code
3999+
class=css>@page</code>’, per WG resolution. This makes a difference
4000+
in error handling even if no such at-rules are defined yet: an
4001+
at-rule, valid or not, ends and lets the next declaration being at a
4002+
{} block without a 〈semicolon〉.
4003+
4004+
<li> The handling of some miscellanous "special" tokens (like an
4005+
unmatched 〈}〉) showing up in various places in the grammar has
4006+
been specified with some reasonable behavior shown by at least one
4007+
browser. Previously, stylesheets with those tokens in those places
4008+
just didn't match the stylesheet grammar at all, so their handling
4009+
was totally undefined. Specifically:
4010+
<ul>
4011+
<li> [] blocks, () blocks and functions can now contain {} blocks,
4012+
〈at-keyword〉s or 〈semicolon〉s
4013+
4014+
<li> Selectors can now contain semicolons
4015+
4016+
<li> Selectors and at-rule preludes can now contain
4017+
〈at-keyword〉s
4018+
</ul>
4019+
</ul>
4020+
4021+
<p> <a href="#anb0"><var>An+B</var></a> changes from Selectors Level 3
4022+
<a href="#SELECT" rel=biblioentry>[SELECT]<!--{{SELECT}}--></a>:
4023+
4024+
<ul>
4025+
<li> The <a href="#anb0"><var>An+B</var></a> microsyntax has now been
4026+
formally defined in terms of CSS tokens, rather than with a separate
4027+
tokenizer. This has resulted in minor differences:
4028+
<ul>
4029+
<li> In values starting with "+n", a space is now allowed between
4030+
the "+" and "n". (This is an accidental consequence of the "+" and
4031+
"n" parsing as separate CSS tokens, and CSS's value grammar
4032+
ignoring whitespace.)
4033+
4034+
<li> In some cases, "-" characters or digits can be escaped (when
4035+
they appear as part of the unit of a 〈dimension〉 or
4036+
〈ident〉).
4037+
</ul>
4038+
</ul>
4039+
<!--
39914040
39924041
TTTTTTTTTTTTTTTTTTTTTTTHHHHHHHHH HHHHHHHHHEEEEEEEEEEEEEEEEEEEEEE
39934042
T:::::::::::::::::::::TH:::::::H H:::::::HE::::::::::::::::::::E
@@ -4026,9 +4075,9 @@ <h3 id=serializing-anb><span class=secno>8.1. </span> Serializing <a
40264075
EEEEEEEEEEEEEEEEEEEEEENNNNNNNN NNNNNNNDDDDDDDDDDDDD
40274076
-->
40284077

4029-
<h2 id=conformance><span class=secno>9. </span> Conformance</h2>
4078+
<h2 id=conformance><span class=secno>10. </span> Conformance</h2>
40304079

4031-
<h3 id=conventions><span class=secno>9.1. </span> Document conventions</h3>
4080+
<h3 id=conventions><span class=secno>10.1. </span> Document conventions</h3>
40324081

40334082
<p>Conformance requirements are expressed with a combination of
40344083
descriptive assertions and RFC 2119 terminology. The key words
@@ -4055,7 +4104,7 @@ <h3 id=conventions><span class=secno>9.1. </span> Document conventions</h3>
40554104

40564105
<p class=note>Note, this is an informative note.
40574106

4058-
<h3 id=conformance-classes><span class=secno>9.2. </span> Conformance
4107+
<h3 id=conformance-classes><span class=secno>10.2. </span> Conformance
40594108
classes</h3>
40604109

40614110
<p>Conformance to CSS Syntax Module Level 3 is defined for three
@@ -4157,7 +4206,7 @@ <h2 class=no-num id=index> Index</h2>
41574206
title="section 2."><strong>2.</strong></a>
41584207

41594208
<li>authoring tool, <a href="#authoring-tool"
4160-
title="section 9.2."><strong>9.2.</strong></a>
4209+
title="section 10.2."><strong>10.2.</strong></a>
41614210

41624211
<li>B, <a href="#b" title="section 6."><strong>6.</strong></a>
41634212

@@ -4361,7 +4410,7 @@ <h2 class=no-num id=index> Index</h2>
43614410
title="section 5.2."><strong>5.2.</strong></a>
43624411

43634412
<li>renderer, <a href="#renderer"
4364-
title="section 9.2."><strong>9.2.</strong></a>
4413+
title="section 10.2."><strong>10.2.</strong></a>
43654414

43664415
<li><var>&lt;rule-list></var>, <a href="#ltrule-list"
43674416
title="section 7.1."><strong>7.1.</strong></a>
@@ -4408,7 +4457,7 @@ <h2 class=no-num id=index> Index</h2>
44084457
<li>style sheet
44094458
<ul>
44104459
<li>as conformance class, <a href="#style-sheet"
4411-
title="section 9.2."><strong>9.2.</strong></a>
4460+
title="section 10.2."><strong>10.2.</strong></a>
44124461
</ul>
44134462

44144463
<li>uppercase letter, <a href="#uppercase-letter"

0 commit comments

Comments
 (0)