[css3-syntax] editorial

Author: tabatkins

css3-syntax/Overview.html

@@ -160,7 +160,8 @@ <h2 class="no-num no-toc" id=contents> Table of contents</h2>
    <li><a href="#syntax-description"><span class=secno>2. </span> Description
     of CSS's Syntax</a>
 
-   <li><a href="#parsing"><span class=secno>3. </span> Parsing</a>
+   <li><a href="#tokenizing-and-parsing-css"><span class=secno>3. </span>
+    Tokenizing and Parsing CSS</a>
     <ul class=toc>
      <li><a href="#overview-of-the-parsing-model"><span class=secno>3.1.
       </span> Overview of the Parsing Model</a>
@@ -483,7 +484,8 @@ <h2 id=syntax-description><span class=secno>2. </span> Description of CSS's
    special syntaxes of individual <a href="#at-rules"><i>at-rules</i></a> can
    be found in the specs that define them.
 
-  <h2 id=parsing><span class=secno>3. </span> Parsing</h2>
+  <h2 id=tokenizing-and-parsing-css><span class=secno>3. </span> Tokenizing
+   and Parsing CSS</h2>
 
   <p> User agents must use the parsing rules described in this section to
    generate the CSSOM trees from text/css resources. Together, these rules
@@ -1989,10 +1991,10 @@ <h3 id=changes-from-css-2.1-tokenizer><span class=secno>3.5. </span>
    be unintentional.
 
   <p> Note that the point of this spec is to match reality; changes from
-   CSS2.1‘<code class=css>s tokenizer are nearly always because the
-   tokenizer specified something that doesn</code>’t match actual browser
-   behavior, or left something unspecified. If some detail doesn't match
-   browsers, please let me know as it's almost certainly unintentional.
+   CSS2.1&apos;s tokenizer are nearly always because the tokenizer specified
+   something that doesn't match actual browser behavior, or left something
+   unspecified. If some detail doesn't match browsers, please let me know as
+   it's almost certainly unintentional.
 
   <ol>
    <li> The DASHMATCH and INCLUDES tokens have been removed. They can instead
@@ -2014,9 +2016,10 @@ <h3 id=changes-from-css-2.1-tokenizer><span class=secno>3.5. </span>
     token is mentioned in other specs). The only consequence of this is that
     comments can no longer be inserted between the sign and the number.
 
-   <li> Several flags have been added for SVG-compatible tokenizing, so that
-    a single state machine can be used for both "vanilla" and SVG CSS
-    parsing.
+   <li> Some flags have been added for SVG-compatible tokenizing, so that a
+    single state machine can be used for both "vanilla" and SVG CSS parsing.
+
+   <li> Scientific notation is supported for numbers, per WG resolution.
   </ol>
   <!--
 PPPPPPPPPPPPPPPPP        AAA               RRRRRRRRRRRRRRRRR      SSSSSSSSSSSSSSS EEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRR   
@@ -2823,22 +2826,15 @@ <h3 id=changes-from-css-2.1-core-grammar><span class=secno>3.7. </span>
     IDENT(important) tokens when processing an !important directive at the
     end of a style rule.
 
-   <li> Scientific notation is supported for numbers, per WG resolution.
-
-   <li> The + sign is now part of the number token that it precedes, rather
-    than always being a separate DELIM(+) token.
-
-   <li> The INCLUDES and DASHMATCH tokens have been dropped. They're not
-    actually necessary (the Selectors parser can handle them as two DELIM
-    tokens just as well) and it's confusing to have them show up in the Core
-    Grammar when the other types of attribute selector options don't.
-
    <li> The handling of some miscellanous ‘<code
     class=property>special</code>’ tokens (like an unmatched } token)
     showing up in various places in the grammar has been specified with some
     reasonable behavior shown by at least one browser. Previously,
     stylesheets with those tokens in those places just didn't match the
     stylesheet grammar at all, so their handling was totally undefined.
+
+   <li> Quirks mode parsing differences are now officially recognized in the
+    parser.
   </ol>
   <!--
     

css3-syntax/Overview.src.html

@@ -210,7 +210,7 @@ <h2 id='syntax-description'>
 		The special syntaxes of individual <i>at-rules</i> can be found in the specs that define them.
 
 <h2>
-Parsing</h2>
+Tokenizing and Parsing CSS</h2>
 
 	<p>
 		User agents must use the parsing rules described in this section to generate the CSSOM trees from text/css resources. 
@@ -1957,7 +1957,7 @@ <h3>
 
 	<p>
 		Note that the point of this spec is to match reality;
-		changes from CSS2.1's tokenizer are nearly always because the tokenizer specified something that doesn't match actual browser behavior,
+		changes from CSS2.1&apos;s tokenizer are nearly always because the tokenizer specified something that doesn't match actual browser behavior,
 		or left something unspecified.
 		If some detail doesn't match browsers,
 		please let me know
@@ -1987,9 +1987,13 @@ <h3>
 			The only consequence of this is that comments can no longer be inserted between the sign and the number.
 
 		<li>
-			Several flags have been added for SVG-compatible tokenizing, 
+			Some flags have been added for SVG-compatible tokenizing, 
 			so that a single state machine can be used for both "vanilla" and SVG CSS parsing.
 
+		<li>
+			Scientific notation is supported for numbers,
+			per WG resolution.
+
 	</ol>
 
 
@@ -2828,28 +2832,16 @@ <h3>
 			No whitespace or comments are allowed between the DELIM(!) and IDENT(important) tokens 
 			when processing an !important directive at the end of a style rule.
 
-		<li>
-			Scientific notation is supported for numbers,
-			per WG resolution.
-
-		<li>
-			The + sign is now part of the number token that it precedes,
-			rather than always being a separate DELIM(+) token.
-
-		<li>
-			The INCLUDES and DASHMATCH tokens have been dropped.
-			They're not actually necessary
-			(the Selectors parser can handle them as two DELIM tokens just as well)
-			and it's confusing to have them show up in the Core Grammar
-			when the other types of attribute selector options don't.
-
 		<li>
 			The handling of some miscellanous 'special' tokens
 			(like an unmatched } token)
 			showing up in various places in the grammar
 			has been specified with some reasonable behavior shown by at least one browser.
 			Previously, stylesheets with those tokens in those places just didn't match the stylesheet grammar at all,
 			so their handling was totally undefined.
+
+		<li>
+			Quirks mode parsing differences are now officially recognized in the parser.
 	</ol>