w3c
diff --git a/‎css-syntax/Overview.bs‎
Lines changed: 68 additions & 23 deletions b/‎css-syntax/Overview.bs‎
Lines changed: 68 additions & 23 deletions
@@ -397,7 +397,7 @@ The input byte stream</h3>
 <h3 id="input-preprocessing">
 Preprocessing the input stream</h3>
 
-	The input stream consists of the <a>code points</a>
+	The <dfn>input stream</dfn> consists of the <a>code points</a>
 	pushed into it as the input byte stream is decoded.
 
 	Before sending the input stream to the tokenizer,
@@ -463,7 +463,7 @@ Tokenization</h2>
 			<<delim-token>> has a value composed of a single <a>code point</a>.
 
 		<li>
-			<<number-token>>, <<percentage-token>>, and <<dimension-token>> have a representation composed of one or more <a>code points</a>, and a numeric value.
+			<<number-token>>, <<percentage-token>>, and <<dimension-token>> have a numeric value.
 			<<number-token>> and <<dimension-token>> additionally have a type flag set to either "integer" or "number".  The type flag defaults to "integer" if not otherwise set.
 			<<dimension-token>> additionally have a unit composed of one or more <a>code points</a>.
 	</ul>
@@ -727,22 +727,22 @@ Definitions</h3>
 
 		<dt><dfn>next input code point</dfn>
 		<dd>
-			The first <a>code point</a> in the input stream that has not yet been consumed.
+			The first <a>code point</a> in the <a>input stream</a> that has not yet been consumed.
 
 		<dt><dfn>current input code point</dfn>
 		<dd>
 			The last <a>code point</a> to have been consumed.
 
 		<dt><dfn>reconsume the current input code point</dfn>
 		<dd>
-			Push the <a>current input code point</a> back onto the front of the input stream,
+			Push the <a>current input code point</a> back onto the front of the <a>input stream</a>,
 			so that the next time you are instructed to consume the <a>next input code point</a>,
 			it will instead reconsume the <a>current input code point</a>.
 
 		<dt><dfn>EOF code point</dfn>
 		<dd>
-			A conceptual <a>code point</a> representing the end of the input stream.
-			Whenever the input stream is empty,
+			A conceptual <a>code point</a> representing the end of the <a>input stream</a>.
+			Whenever the <a>input stream</a> is empty,
 			the <a>next input code point</a> is always an EOF code point.
 
 		<dt><dfn export>digit</dfn>
@@ -817,6 +817,33 @@ Definitions</h3>
 			<<hash-token>> with the "id" ty
8000
pe flag,
 			and the unit of <<dimension-token>>.
 
+		<dt><dfn>representation</dfn>
+		<dd>
+			The <a>representation</a> of a token
+			is the subsequence of the <a>input stream</a>
+			consumed by the invocation of the <a>consume a token</a> algorithm
+			that produced it.
+			This is preserved for a few algorithms that rely on subtle details of the input text,
+			which a simple "re-serialization" of the tokens might disturb.
+
+			The <a>representation</a> is only consumed by internal algorithms,
+			and never directly exposed,
+			so it's not actually required to preserve the exact text;
+			equivalent methods,
+			such as associating each token with offsets into the source text,
+			also suffice.
+
+			Note: In particular, the <a>representation</a> preserves details
+			such as whether .009 was written as ''.009'' or ''9e-3'',
+			and whether a character was written literally
+			or as a CSS escape.
+			The former is necessary to properly parse <<urange>> productions;
+			the latter is basically an accidental leak of the tokenizing abstraction,
+			but allowed because it makes the impl easier to define.
+
+			If a token is ever produced by an algorithm directly,
+			rather than thru the tokenization algorithm in this specification,
+			its representation is the empty string.
 	</dl>
 
 <!--
@@ -1063,7 +1090,7 @@ Consume a numeric token</h4>
 	then:
 
 	<ol>
-		<li>Create a <<dimension-token>> with the same representation, value, and type flag as the returned number,
+		<li>Create a <<dimension-token>> with the same value and type flag as the returned number,
 			and a unit set initially to the empty string.
 
 		<li><a>Consume a name</a>.
@@ -1075,11 +1102,11 @@ Consume a numeric token</h4>
 	Otherwise,
 	if the <a>next input code point</a> is U+0025 PERCENTAGE SIGN (%),
 	consume it.
-	Create a <<percentage-token>> with the same representation and value as the returned number,
+	Create a <<percentage-token>> with the same value as the returned number,
 	and return it.
 
 	Otherwise,
-	create a <<number-token>> with the same representation, value, and type flag as the returned number,
+	create a <<number-token>> with the same value and type flag as the returned number,
 	and return it.
 
 
@@ -1431,10 +1458,8 @@ Consume a name</h4>
 Consume a number</h4>
 
 	This section describes how to <dfn>consume a number</dfn> from a stream of <a>code points</a>.
-	It returns a 3-tuple of
-	a string representation,
-	a numeric value,
-	and a type flag which is either "integer" or "number".
+	It returns a numeric |value|,
+	and a |type| which is either "integer" or "number".
 
 	Note: This algorithm does not do the verification of the first few <a>code points</a>
 	that are necessary to ensure a number can be obtained from the stream.
@@ -1445,8 +1470,8 @@ Consume a number</h4>
 
 	<ol>
 		<li>
-			Initially set <var>repr</var> to the empty string
-			and <var>type</var> to "integer".
+			Initially set <var>type</var> to "integer".
+			Let |repr| be the empty string.
 
 		<li>
 			If the <a>next input code point</a> is U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-),
@@ -1487,7 +1512,7 @@ Consume a number</h4>
 			and set the <var>value</var> to the returned value.
 
 		<li>
-			Return a 3-tuple of <var>repr</var>, <var>value</var>, and <var>type</var>.
+			Return <var>value</var> and <var>type</var>.
 	</ol>
 
 
@@ -1967,8 +1992,8 @@ Parse something according to a CSS grammar</h4>
 	or the result of parsing the input according to the grammar,
 	which is an unspecified structure corresponding to the provided grammar specification.
 	The return value must only be interacted with by specification prose,
-	where the representation ambiguity is not problematic
-	if it is meant to be exposed outside of spec language,
+	where the representation ambiguity is not problematic.
+	If it is meant to be exposed outside of spec language,
 	the spec using the result must explicitly translate it into a well-specified representation,
 	such as, for example, by invoking a CSS serialization algorithm
 	(like "serialize as a CSS <<string>> value").
@@ -2660,8 +2685,8 @@ The <code>&lt;an+b></code> type</h3>
 		<li><dfn><code>&lt;ndashdigit-ident></code></dfn> is an <<ident-token>> whose value is an <a>ASCII case-insensitive</a> match for "n-*", where "*" is a series of one or more <a>digits</a>
 		<li><dfn><code>&lt;dashndashdigit-ident></code></dfn> is an <<ident-token>> whose value is an <a>ASCII case-insensitive</a> match for "-n-*", where "*" is a series of one or more <a>digits</a>
 		<li><dfn><code>&lt;integer></code></dfn> is a <<number-token>> with its type flag set to "integer"
-		<li><dfn><code>&lt;signed-integer></code></dfn> is a <<number-token>> with its type flag set to "integer", and whose representation starts with "+" or "-"
-		<li><dfn><code>&lt;signless-integer></code></dfn> is a <<number-token>> with its type flag set to "integer", and whose representation start with a <a>digit</a>
+		<li><dfn><code>&lt;signed-integer></code></dfn> is a <<number-token>> with its type flag set to "integer", and whose <a>representation</a> starts with "+" or "-"
+		<li><dfn><code>&lt;signless-integer></code></dfn> is a <<number-token>> with its type flag set to "integer", and whose <a>representation</a> start with a <a>digit</a>
 	</ul>
 
 	<p id="anb-plus">
@@ -2779,6 +2804,28 @@ The <<urange>> type</h3>
 	in terms of existing CSS tokens,
 	and how to interpret it as a range of unicode codepoints.
 
+	<details class=note>
+		<summary>What are the confusing collisions?</summary>
+
+		For example, in the CSS <nobr>''u + a { color: green; }''</nobr>,
+		the intended meaning is that an <code>a</code> element
+		following a <code>u</code> element
+		should be colored green.
+		Whitespace is not normally required between combinators
+		and the surrounding selectors,
+		so it <em>should</em> be equivalent to minify it to
+		<nobr>''u+a{color:green;}''</nobr>.
+
+		With any other combinator, the two pieces of CSS would be equivalent,
+		but due to the previous existence of a specialized unicode-range token,
+		the selector portion of the minified code now contains a unicode-range,
+		not two idents and a combinator.
+		It thus fails to match the Selectors grammar,
+		and the rule is thrown out as invalid.
+
+		(This example is taken from a real-world bug reported to Firefox.)
+	</details>
+
 	Note: The syntax described here is intentionally very low-level,
 	and geared toward implementors.
 	Authors should instead read the informal syntax description in the previous section,
@@ -2808,9 +2855,7 @@ The <<urange>> type</h3>
 	execute the following steps in order:
 
 	1. Skipping the first ''u'' token,
-		concatenate the representations of all the tokens in the production together
-		(or, in the case of <<dimension-token>>s,
-		the representation followed by the unit).
+		concatenate the <a>representations</a> of all the tokens in the production together.
 		Let this be <var>text</var>.
 
 	2. If the first character of <var>text</var> is U+002B PLUS SIGN,