The <FONT> Bug
Internet Explorer's implementation of the DOM does not handle the <FONT> tag correctly . The problem is that the DOM always assumes there is a text entry following the closing </FONT> tag. Putting it differently, the DOM assumes there is a text entry between the opening <FONT> tag and the closing </FONT> tag, as well as after the closing </FONT> tag. Let's examine the following example:
<HTML>
<HEAD>
<TITLE> DOM Demo </TITLE>
</HEAD>
<BODY ID="bodyNode">
<FONT SIZE="5">This is the document body.</FONT>
<P ID = "p1Node"><FONT SIZE="5">This is paragraph 1.</FONT>
</P>
</BODY>
</HTML>
It looks like a fairly trivial document to analyze. Try to synthesize its DOM tree on a piece of paper. Compare your answer with our textbook solution. Let's examine now the actual DOM that Internet Explorer generates for the above example. The following script displays the above example and prints most of the its DOM's node names. Here is the output of the script:
bodyNode.firstChild.nodeName = FONT
bodyNode.firstChild.firstChild.nodeName = #text
bodyNode.childNodes[1].nodeName = #text
bodyNode.childNodes[2].nodeName = P
bodyNode.childNodes[2].firstChild.nodeName = FONT
bodyNode.childNodes[2].firstChild.firstChild.nodeName = #text
bodyNode.childNodes[2].childNodes[1].nodeName = #text
The sketch of the DOM tree clearly shows where the problems are. The best indication of the bug is the child text node of bodyNode. By looking at the example document above, you would expect bodyNode to have two children: a <FONT> node and a <P> node. Instead, it has three children: a <FONT> node, a text node (bodyNode.childNodes[1].nodeName = #text), and a <P> node. Also, you would expect the <P> node to have a single <FONT> node. Instead, the <P> node has two children: a <FONT> node and a text node (bodyNode.childNodes[2].childNodes[1].nodeName = #text). In both cases, it looks like the browser assumes a textual entry at the end of every <FONT> element. Here is a document that would fit the DOM representation that Internet Explorer mistakenly generates for the document at the head of this page:
<HTML>
<HEAD>
<TITLE> DOM Demo </TITLE>
</HEAD>
<BODY ID="bodyNode">
<FONT SIZE="5">This is the document body.</FONT>blablabla
<P ID = "p1Node"><FONT SIZE="5">This is paragraph 1.</FONT>foobar
</P>
</BODY>
</HTML>
You can redo the previous exercise and print the DOM nodes with the same script. Compare the output statements to those above. They are identical. Internet Explorer generates an identical DOM tree for two different documents!
You are probably wondering how to get around the problem. Luckily, there is a way. You just need to avoid a new line at the trail of a <FONT> element. Here is a new script that will avoid the bug:
<HTML>
<HEAD>
<TITLE> DOM Demo </TITLE>
</HEAD>
<BODY ID="bodyNode">
<FONT SIZE="5">This is the document body.</FONT><P ID = "p1Node">
<FONT SIZE="5">This is paragraph 1.</FONT></P>
</BODY>
</HTML>
The following script proves that the DOM representation is correct this time. Here is the printout:
bodyNode.firstChild.nodeName = FONT
bodyNode.firstChild.firstChild.nodeName = #text
bodyNode.childNodes[1].nodeName = P
  
| 
