[html5] r2704 - [t] (0) Oops, Unicode characters can be up to six digits hex, not five.

[whatwg at whatwg.org]

Author: ianh
Date: 2009-01-23 17:54:40 -0800 (Fri, 23 Jan 2009)
New Revision: 2704

Modified:
   index
   source
Log:
[t] (0) Oops, Unicode characters can be up to six digits hex, not five.

Modified: index
===================================================================
--- index	2009-01-24 01:52:21 UTC (rev 2703)
+++ index	2009-01-24 01:54:40 UTC (rev 2704)
@@ -52972,15 +52972,14 @@
   all element and attribute local names that the API wouldn't support
   to a set of names that <em>are</em> allowed, by replacing any
   character that isn't supported with the uppercase letter U and the
-  five digits of the character's Unicode codepoint when expressed in
+  six digits of the character's Unicode codepoint when expressed in
   hexadecimal, using digits 0-9 and capital letters A-F as the
   symbols, in increasing numeric order.</p>
 
   <p class=example>For example, the element name <code title="">foo<bar</code>, which can be output by the <a href=#html-parser>HTML
   parser</a>, though it is neither a legal HTML element name nor a
-  well-formed XML element name, would be converted into <code title="">fooU0003Cbar</code>, which <em>is</em> a well-formed
-  XML element name (though it's still not legal in HTML by any
-  means).</p>
+  well-formed XML element name, would be converted into <code title="">fooU00003Cbar</code>, which <em>is</em> a well-formed XML
+  element name (though it's still not legal in HTML by any means).</p>
 
   <p class=example>As another example, consider the attribute
   <code>xlink:href</code>. Used on a MathML element, it becomes, after
@@ -52989,7 +52988,7 @@
   name "<code title="">href</code>". However, used on an HTML element,
   it becomes an attribute with no prefix and the local name "<code title="">xlink:href</code>", which is not a valid NCName, and thus
   might not be accepted by an XML API. It could thus get converted,
-  becoming "<code title="">xlinkU0003Ahref</code>".</p>
+  becoming "<code title="">xlinkU00003Ahref</code>".</p>
 
   <p class=note>The resulting names from this conversion
   conveniently can't clash with any attribute generated by the
@@ -53024,9 +53023,9 @@
   <em>after</em> the <a href=#html-parser>HTML parser</a>'s rules have been
   applied. For example, a <code title=""><a::></code> start tag
   will be closed by a <code title=""></a::></code> end tag, and
-  never by a <code title=""></aU0003AU0003A></code> end tag, even
+  never by a <code title=""></aU00003AU00003A></code> end tag, even
   if the user agent is using the rules above to then generate an
-  actual element in the DOM with the name <code title="">aU0003AU0003A</code> for that start tag.</p>
+  actual element in the DOM with the name <code title="">aU00003AU00003A</code> for that start tag.</p>
 
 
 

Modified: source
===================================================================
--- source	2009-01-24 01:52:21 UTC (rev 2703)
+++ source	2009-01-24 01:54:40 UTC (rev 2704)
@@ -60322,7 +60322,7 @@
   all element and attribute local names that the API wouldn't support
   to a set of names that <em>are</em> allowed, by replacing any
   character that isn't supported with the uppercase letter U and the
-  five digits of the character's Unicode codepoint when expressed in
+  six digits of the character's Unicode codepoint when expressed in
   hexadecimal, using digits 0-9 and capital letters A-F as the
   symbols, in increasing numeric order.</p>
 
@@ -60330,9 +60330,8 @@
   title="">foo<bar</code>, which can be output by the <span>HTML
   parser</span>, though it is neither a legal HTML element name nor a
   well-formed XML element name, would be converted into <code
-  title="">fooU0003Cbar</code>, which <em>is</em> a well-formed
-  XML element name (though it's still not legal in HTML by any
-  means).</p>
+  title="">fooU00003Cbar</code>, which <em>is</em> a well-formed XML
+  element name (though it's still not legal in HTML by any means).</p>
 
   <p class="example">As another example, consider the attribute
   <code>xlink:href</code>. Used on a MathML element, it becomes, after
@@ -60342,7 +60341,7 @@
   it becomes an attribute with no prefix and the local name "<code
   title="">xlink:href</code>", which is not a valid NCName, and thus
   might not be accepted by an XML API. It could thus get converted,
-  becoming "<code title="">xlinkU0003Ahref</code>".</p>
+  becoming "<code title="">xlinkU00003Ahref</code>".</p>
 
   <p class="note">The resulting names from this conversion
   conveniently can't clash with any attribute generated by the
@@ -60381,10 +60380,10 @@
   <em>after</em> the <span>HTML parser</span>'s rules have been
   applied. For example, a <code title=""><a::></code> start tag
   will be closed by a <code title=""></a::></code> end tag, and
-  never by a <code title=""></aU0003AU0003A></code> end tag, even
+  never by a <code title=""></aU00003AU00003A></code> end tag, even
   if the user agent is using the rules above to then generate an
   actual element in the DOM with the name <code
-  title="">aU0003AU0003A</code> for that start tag.</p>
+  title="">aU00003AU00003A</code> for that start tag.</p>