[html5] r3939 - [e] (0) Cleanup around parser, add some 'impl' classes I'd accidentally left out.

whatwg at whatwg.org whatwg at whatwg.org
Mon Sep 21 16:29:48 PDT 2009


Author: ianh
Date: 2009-09-21 16:29:47 -0700 (Mon, 21 Sep 2009)
New Revision: 3939

Modified:
   index
   source
Log:
[e] (0) Cleanup around parser, add some 'impl' classes I'd accidentally left out.

Modified: index
===================================================================
--- index	2009-09-21 23:26:03 UTC (rev 3938)
+++ index	2009-09-21 23:29:47 UTC (rev 3939)
@@ -16101,7 +16101,7 @@
 
    </dd>
 
-  </dl><div>
+  </dl><div class=impl>
 
   <p>The <dfn id=dom-time-valueasdate title=dom-time-valueAsDate><code>valueAsDate</code></dfn> IDL
   attribute must return either null or a new <code>Date</code> object
@@ -16901,7 +16901,7 @@
 
     <p>For an indeterminate progress bar, returns −1.</p>
 
-  </dl><div>
+  </dl><div class=impl>
 
   <p>If the progress bar is an indeterminate progress bar, then the
   <dfn id=dom-progress-position title=dom-progress-position><code>position</code></dfn> IDL
@@ -64350,6 +64350,13 @@
 
   <div class=impl>
 
+  <!-- v2: One thing that this doesn't define is handling deeply
+  nested documents. There are compatibility requirements around that:
+  you can't throw away the elements altogether, consider Tux made only
+  with opening <font> elements, one per character. Seems that the best
+  thing to do is to close some formatting elements from the middle of
+  the stack when you hit a limit, or something. -->
+
   <h4 id=tree-construction><span class=secno>9.2.5 </span><dfn>Tree construction</dfn></h4>
 
   <p>The input to the tree construction stage is a sequence of tokens
@@ -68014,74 +68021,6 @@
   </ol><p>The <a href=#task-source>task source</a> for these <span title=concept-tasks>tasks</span> is the <a href=#dom-manipulation-task-source>DOM manipulation
   task source</a>.</p>
 
-
-<!--XXX need to handle
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#2354
-2354           // Don't open transient styles if it makes the stack deep, bug 58917.
--->
-
-<!--XXX
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsHTMLTokenizer.cpp#749
--->
-
-<!--
-see also  CTextToken::ConsumeCharacterData()  for CDATA parsing?
-
-1212                      1  Here's a tricky case from bug 22596:  <h5><li><h5>
-1213                         How do we know that the 2nd <h5> should close the <LI> rather than nest inside the <LI>?
-1214                         (Afterall, the <h5> is a legal child of the <LI>).
-1215
-1216                         The way you know is that there is no root between the two, so the <h5> binds more
-1217                         tightly to the 1st <h5> than to the <LI>.
-1218                      2. Also, bug 6148 shows this case: <SPAN><DIV><SPAN>
-1219                         From this case we learned not to execute this logic if the parent is a block.
-1220
-1221                      3. Fix for 26583
-1222                         Ex. <A href=foo.html><B>foo<A href-bar.html>bar</A></B></A>  <- A legal HTML
-1223                         In the above example clicking on "foo" or "bar" should link to
-1224                         foo.html or bar.html respectively. That is, the inner <A> should be informed
-1225                         about the presence of an open <A> above <B>..so that the inner <A> can close out
-1226                         the outer <A>. The following code does it for us.
-1227
-1228                      4. Fix for 27865 [ similer to 22596 ]. Ex: <DL><DD><LI>one<DD><LI>two
- - http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#1211
-
-815             // Here's a problem.  If theTag is legal in here, we don't move it
-816             // out.  So if we're moving stuff out of here, the parent of theTag
-817             // gets closed at this point.  But some things are legal
-818             // _everywhere_ and hence would effectively close out misplaced
-819             // content in tables.  This is undesirable, so treat them as
-820             // illegal here so they'll be shipped out with their parents and
-821             // siblings.  See bug 40855 for an explanation (that bug was for
-822             // comments, but the same issues arise with whitespace, newlines,
-823             // noscript, etc).  Script is special, though.  Shipping it out
-824             // breaks document.write stuff.  See bug 243064.
- - http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#825
-
-
-1326     /**************************************************************************************
-1327      *
-1328      * Now a little code to deal with bug #49687 (crash when layout stack gets too deep)
-1329      * I've also opened this up to any container (not just inlines): re bug 55095
-1330      * Improved to handle bug 55980 (infinite loop caused when DEPTH is exceeded and
-1331      * </P> is encountered by itself (<P>) is continuously produced.
-1332      *
-1333      **************************************************************************************/
-
-1912               // Oh boy!! we found a "stray" tag. Nav4.x and IE introduce line break in
-1913               // such cases. So, let's simulate that effect for compatibility.
-1914               // Ex. <html><body>Hello</P>There</body></html>
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#1912
-
-http://lxr.mozilla.org/seamonkey/search?string=nested
-/parser/htmlparser/src/CNavDTD.cpp, line 791 - * 2. <CENTER><DL><DT><A><CENTER> allow nested <CENTER>
-/parser/htmlparser/src/CNavDTD.cpp, line 792 - * 3. <TABLE><TR><TD><TABLE>... allow nested <TABLE>
-/parser/htmlparser/src/CNavDTD.cpp, line 2562 - // Discard nested forms - bug 72639
-/parser/htmlparser/src/nsElementTable.cpp, line 1453 - * 2. <CENTER><DL><DT><A><CENTER> allow nested <CENTER>
-/parser/htmlparser/src/nsElementTable.cpp, line 1454 - * 3. <TABLE><TR><TD><TABLE>... allow nested <TABLE>
-/parser/htmlparser/src/nsElementTable.cpp, line 1901 - // Ex: <H1><LI><H1><LI>. Inner LI has the potential of getting nested
--->
-
   </div>
 
 

Modified: source
===================================================================
--- source	2009-09-21 23:26:03 UTC (rev 3938)
+++ source	2009-09-21 23:29:47 UTC (rev 3939)
@@ -17174,7 +17174,7 @@
 
   </dl>
 
-  <div>
+  <div class="impl">
 
   <p>The <dfn
   title="dom-time-valueAsDate"><code>valueAsDate</code></dfn> IDL
@@ -18034,7 +18034,7 @@
 
   </dl>
 
-  <div>
+  <div class="impl">
 
   <p>If the progress bar is an indeterminate progress bar, then the
   <dfn title="dom-progress-position"><code>position</code></dfn> IDL
@@ -79297,6 +79297,13 @@
 
   <div class="impl">
 
+  <!-- v2: One thing that this doesn't define is handling deeply
+  nested documents. There are compatibility requirements around that:
+  you can't throw away the elements altogether, consider Tux made only
+  with opening <font> elements, one per character. Seems that the best
+  thing to do is to close some formatting elements from the middle of
+  the stack when you hit a limit, or something. -->
+
   <h4><dfn>Tree construction</dfn></h4>
 
   <p>The input to the tree construction stage is a sequence of tokens
@@ -83343,74 +83350,6 @@
   title="concept-tasks">tasks</span> is the <span>DOM manipulation
   task source</span>.</p>
 
-
-<!--XXX need to handle
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#2354
-2354           // Don't open transient styles if it makes the stack deep, bug 58917.
--->
-
-<!--XXX
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/nsHTMLTokenizer.cpp#749
--->
-
-<!--
-see also  CTextToken::ConsumeCharacterData()  for CDATA parsing?
-
-1212                      1  Here's a tricky case from bug 22596:  <h5><li><h5>
-1213                         How do we know that the 2nd <h5> should close the <LI> rather than nest inside the <LI>?
-1214                         (Afterall, the <h5> is a legal child of the <LI>).
-1215
-1216                         The way you know is that there is no root between the two, so the <h5> binds more
-1217                         tightly to the 1st <h5> than to the <LI>.
-1218                      2. Also, bug 6148 shows this case: <SPAN><DIV><SPAN>
-1219                         From this case we learned not to execute this logic if the parent is a block.
-1220
-1221                      3. Fix for 26583
-1222                         Ex. <A href=foo.html><B>foo<A href-bar.html>bar</A></B></A>  <- A legal HTML
-1223                         In the above example clicking on "foo" or "bar" should link to
-1224                         foo.html or bar.html respectively. That is, the inner <A> should be informed
-1225                         about the presence of an open <A> above <B>..so that the inner <A> can close out
-1226                         the outer <A>. The following code does it for us.
-1227
-1228                      4. Fix for 27865 [ similer to 22596 ]. Ex: <DL><DD><LI>one<DD><LI>two
- - http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#1211
-
-815             // Here's a problem.  If theTag is legal in here, we don't move it
-816             // out.  So if we're moving stuff out of here, the parent of theTag
-817             // gets closed at this point.  But some things are legal
-818             // _everywhere_ and hence would effectively close out misplaced
-819             // content in tables.  This is undesirable, so treat them as
-820             // illegal here so they'll be shipped out with their parents and
-821             // siblings.  See bug 40855 for an explanation (that bug was for
-822             // comments, but the same issues arise with whitespace, newlines,
-823             // noscript, etc).  Script is special, though.  Shipping it out
-824             // breaks document.write stuff.  See bug 243064.
- - http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#825
-
-
-1326     /**************************************************************************************
-1327      *
-1328      * Now a little code to deal with bug #49687 (crash when layout stack gets too deep)
-1329      * I've also opened this up to any container (not just inlines): re bug 55095
-1330      * Improved to handle bug 55980 (infinite loop caused when DEPTH is exceeded and
-1331      * </P> is encountered by itself (<P>) is continuously produced.
-1332      *
-1333      **************************************************************************************/
-
-1912               // Oh boy!! we found a "stray" tag. Nav4.x and IE introduce line break in
-1913               // such cases. So, let's simulate that effect for compatibility.
-1914               // Ex. <html><body>Hello</P>There</body></html>
-http://lxr.mozilla.org/mozilla/source/parser/htmlparser/src/CNavDTD.cpp#1912
-
-http://lxr.mozilla.org/seamonkey/search?string=nested
-/parser/htmlparser/src/CNavDTD.cpp, line 791 - * 2. <CENTER><DL><DT><A><CENTER> allow nested <CENTER>
-/parser/htmlparser/src/CNavDTD.cpp, line 792 - * 3. <TABLE><TR><TD><TABLE>... allow nested <TABLE>
-/parser/htmlparser/src/CNavDTD.cpp, line 2562 - // Discard nested forms - bug 72639
-/parser/htmlparser/src/nsElementTable.cpp, line 1453 - * 2. <CENTER><DL><DT><A><CENTER> allow nested <CENTER>
-/parser/htmlparser/src/nsElementTable.cpp, line 1454 - * 3. <TABLE><TR><TD><TABLE>... allow nested <TABLE>
-/parser/htmlparser/src/nsElementTable.cpp, line 1901 - // Ex: <H1><LI><H1><LI>. Inner LI has the potential of getting nested
--->
-
   </div>
 
 




More information about the Commit-Watchers mailing list