[css-syntax-3] Per WG resolution, restrict non-ASCII ident code points to the same list that HTML allows in custom element names. #7129

Author: tabatkins

css-syntax-3/Overview.bs

@@ -786,14 +786,69 @@ Definitions</h3>
 			An <a>uppercase letter</a>
 			or a <a>lowercase letter</a>.
 
-		<dt><dfn export>non-ASCII code point</dfn>
-		<dd>
-			A <a>code point</a> with a value equal to or greater than U+0080 &lt;control>.
+		<dt><dfn export>non-ASCII ident code point</dfn>
+		<dd>
+			A <a>code point</a> whose value is any of:
+
+			* U+00B7
+			* between U+00C0 and U+00D6
+			* between U+00D8 and U+00F6
+			* between U+00F8 and U+037D
+			* between U+037F and U+1FFF
+			* U+200C
+			* U+200D
+			* U+203F
+			* U+2040
+			* between U+2070 and U+218F
+			* between U+2C00 and U+2FEF
+			* between U+3001 and U+D7FF
+			* between U+F900 and U+FDCF
+			* between U+FDF0 and U+FFFD
+			* greater than or equal to U+10000
+
+			<details class=note>
+				<summary>Why these character, specifically?</summary>
+
+				This matches the list of non-ASCII codepoints
+				allowed to be used in HTML [=valid custom element names=].
+				It excludes a number of characters that appear as whitespace,
+				or that can cause rendering or parsing issues in some tools,
+				such as the direction override codepoints.
+
+				Note that this is a weaker set of restrictions
+				than <a href="https://unicode.org/reports/tr31/#Figure_Code_Point_Categories_for_Identifier_Parsing">UAX 31</a>
+				recommends for identifiers
+				(used by languages such as JavaScript to restrict their identifier syntax),
+				allowing things such as
+				starting an identifier with a combining character.
+				Consistency with HTML custom element names
+				(and thus, the ability to write selectors for all custom elements
+				without having to use escapes)
+				was considered valuable,
+				and the set of characters restricted by HTML
+				covers the "high value" restrictions well.
+
+				These restrictions do not avoid all possible confusing renderings;
+				mixing characters from LTR and RTL scripts
+				can still result in unexpected visual transposition
+				in most text editors,
+				for example.
+				Source text can contain the restricted characters in non-ident contexts, as well:
+				most of them are completely valid in strings, for example.
+				Even when used in a way that creates invalid CSS,
+				the parsing errors they cause might be limited to something unimportant,
+				while their effect on rendering the source text in code review tools
+				might be significant and/or malicious.
+				For more details on these sorts of "source text attacks",
+				see <a href="https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html">this Rust-lang blog post</a>
+				<small><a href="https://web.archive.org/web/20220323175009/https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html">(archived)</a></small>.
+			</details>
+
 
 		<dt><dfn export lt="ident-start code point | name-start code point" oldids="name-start-code-point, identifier-start-code-point">ident-start code point</dfn>
 		<dd>
 			A <a>letter</a>,
-			a <a>non-ASCII code point</a>,
+			a <a>non-ASCII ident code point</a>,
 			or U+005F LOW LINE (_).
 
 		<dt><dfn export lt="ident code point" oldids="name-code-point, identifier-code-point">ident code point</dfn>
@@ -2122,7 +2177,7 @@ Parse A Comma-Separated List According To A CSS Grammar</h4>
 Parse a stylesheet</h4>
 
 	<div algorithm>
-		To <dfn export>parse a stylesheet</dfn> from an |input| 
+		To <dfn export>parse a stylesheet</dfn> from an |input|
 		given an optional [=/url=] |location|:
 
 		<ol>
@@ -3923,11 +3978,8 @@ Changes from CSS 2.1 and Selectors Level 3</h3>
 			-->
 
 		<li>
-			The definition of <a>non-ASCII code point</a> was changed
-			to be consistent with every definition of ASCII.
-			This affects <a>code points</a> U+0080 to U+009F,
-			which are now <a>ident code points</a> rather than <<delim-token>>s,
-			like the rest of <a>non-ASCII code points</a>.
+			The definition of <a>non-ASCII ident code point</a> was changed
+			to be consistent with HTML's [=valid custom elements names=].
 
 		<li>
 			Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore.