Skip to content

Commit

Permalink
[e] (0) Cleanup around parser, add some 'impl' classes I'd accidental…
Browse files Browse the repository at this point in the history 
…ly left out.

git-svn-id: http://svn.whatwg.org/webapps@3939 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
@Hixie
Hixie committed Sep 21, 2009
1 parent 0259512 commit 6897fa1
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 140 deletions.
79 changes: 9 additions & 70 deletions index
View file
Expand Up @@ -16101,7 +16101,7 @@ this specification: the <abbr>WHATWG</abbr> and the

</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
Expand Down Expand Up @@ -16901,7 +16901,7 @@ wormhole connection.&lt;/mark&gt;&lt;/p&gt;</pre>

<p>For an indeterminate progress bar, returns &minus;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
Expand Down Expand Up @@ -64350,6 +64350,13 @@ interface <dfn id=messageport>MessagePort</dfn> {

<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
Expand Down Expand Up @@ -68014,74 +68021,6 @@ document.body.appendChild(text);
</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>


Expand Down
79 changes: 9 additions & 70 deletions source
View file
Expand Up @@ -17174,7 +17174,7 @@ this specification: the &lt;abbr>WHATWG&lt;/abbr> and the

</dl>

<div>
<div class="impl">

<p>The <dfn
title="dom-time-valueAsDate"><code>valueAsDate</code></dfn> IDL
Expand Down Expand Up @@ -18034,7 +18034,7 @@ wormhole connection.&lt;/mark>&lt;/p></pre>

</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
Expand Down Expand Up @@ -79297,6 +79297,13 @@ interface <dfn>MessagePort</dfn> {

<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
Expand Down Expand Up @@ -83343,74 +83350,6 @@ document.body.appendChild(text);
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>


Expand Down

0 comments on commit 6897fa1

Please sign in to comment.