Different number of children in IE, Firefox and Opera

Thierry Lam

I have the follownig codes:

<html>
<head>
<title>Simple doc</title>
</head>
<body>
<script type="text/javascript">
function greet()
{
var table = document.getElementById("greetTable");
var cell = table.rows[0].cells[1];

var output = cell.childNodes.length;

alert(output);
}

</script>
<input type="checkbox" name="greet" onClick="greet()"/>Key Greet
<table id="greetTable" border="1">
<tr>
<td>Hello</td>
<td>
<div id="first">
<input type="button" value="hello world" onClick="say()" />
</div>
<div id="second">
Text Only
</div>
</td>
</tr>
</table>
</body>
</html>

When you click on the checkbox, it will show you how many children
cell[0,1] has. On Firefox 1.5.0.10 and Opera 9.01, the popup show 5
children. On IE 6.0.2900.2180, it shows 2 children which is the
correct answer. Can anyone tell me why it's show 5 children on the
other browsers?

Isn't the cell at [0,1] supposed to have 2 children only, div first
and div second?

Thanks
Thierry

Mar 6 '07 #1

Follow Post Reply

5168

Jason

On Mar 5, 9:32 pm, "Thierry Lam" <lamthie...@gmail.comwrote:

I have the follownig codes:

<html>
<head>
<title>Simple doc</title>
</head>
<body>
<script type="text/javascript">
function greet()
{
var table = document.getElementById("greetTable");
var cell = table.rows[0].cells[1];

var output = cell.childNodes.length;

alert(output);
}

</script>
<input type="checkbox" name="greet" onClick="greet()"/>Key Greet
<table id="greetTable" border="1">
<tr>
<td>Hello</td>
<td>
<div id="first">
<input type="button" value="hello world" onClick="say()" />
</div>
<div id="second">
Text Only
</div>
</td>
</tr>
</table>
</body>
</html>

When you click on the checkbox, it will show you how many children
cell[0,1] has. On Firefox 1.5.0.10 and Opera 9.01, the popup show 5
children. On IE 6.0.2900.2180, it shows 2 children which is the
correct answer. Can anyone tell me why it's show 5 children on the
other browsers?

Isn't the cell at [0,1] supposed to have 2 children only, div first
and div second?

Thanks
Thierry

If you remove all the whitespace in between the divs and tds
(<td><div id="first"><input type="button" value="hello world"
onclick="say()" /></div><div id="second">Text Only</div></td>)
it returns 2 in firefox. Firefox seems to interpret the whitespace as
nodes of type "#text".

Remove the whitespace and it works as you would expect.

-Jason

Mar 6 '07 #2

RobG

On Mar 6, 12:32 pm, "Thierry Lam" <lamthie...@gmail.comwrote:

I have the follownig codes:

[...]

<td>
<div id="first">
<input type="button" value="hello world" onClick="say()" />
</div>
<div id="second">
Text Only
</div>
</td>

[...]

When you click on the checkbox, it will show you how many children
cell[0,1] has. On Firefox 1.5.0.10 and Opera 9.01, the popup show 5
children. On IE 6.0.2900.2180, it shows 2 children which is the
correct answer. Can anyone tell me why it's show 5 children on the
other browsers?

Because browser developers disagree on how to interpret the W3C
specification in regard to the maintenance of whitespace in the source
markup. There is an extensive (if difficult to follow) discussion
here:

<URL: https://bugzilla.mozilla.org/show_bug.cgi?id=26179 >

The first response (from a Mozilla developer) sums up the situation:

"The "phantom" text nodes are actually the newlines between the
elements. The DOM spec says that these text nodes can (but don't
have to be) be preserved and represented in the DOM. We choose to
do so, so that document roundtripping can occur. Since IE doesn't,
it does unfortunately mean that you have to code around them.
Specifically, scripts that use hardcoded childNode offsets will
not work across browsers.

"We might consider getting rid of these small text nodes for
efficiency reasons. For now, we've made the explicit decision
to keep them."

That was in February 2000. The situation hasn't changed, I don't
expect it will any time soon.

Isn't the cell at [0,1] supposed to have 2 children only, div first
and div second?

Maybe, maybe not - it depends on who you ask. ;-)
--
Rob

Mar 6 '07 #3

Isn't the cell at [0,1] supposed to have 2 children only, div first

and div second?

Maybe, maybe not - it depends on who you ask. ;-)

And be careful of who are you asking :-) or your health may get in the
same danger as after asking a religious fanatic "Are you sure God does
exist?" or something :-) I personally rate this rwar topic as the
second hottest one in the programming history - right after the
question of "where to place block parenthesis in my code?". Alas
unlike the first one it has a direct and noticeable program
functioning impact.

<http://en.wikipedia.org/wiki/Phantom_nodesexists almost two years
by now and this is its perpetual state all this time (see the
article).

Actually I invite everyone having an opinion on the subject to express
it at
<http://en.wikipedia.org/wiki/Talk:Phantom_nodes>

That would help to take a decision over the subject. The ones
considering phantom nodes as a wrong and harmful decision are a bit
tired of monthly rolls and furious discussions over each article,
preposition and adjective in a two-paragraphs text. If there is
absolutely no way to describe the phenomenon in a mutually acceptable
way (thus the mention itself of the phenomenon is considered as non-
acceptable by other side) then the article should be either removed or
frozen in some final state by request by Wikipedia team - such cases
do exist already.

Mar 6 '07 #4

Richard Cornford

On Mar 6, 5:02 am, "RobG" <r...@iinet.net.auwrote:

On Mar 6, 12:32 pm, "Thierry Lam" <lamthie...@gmail.comwrote:

<snip>

>When you click on the checkbox, it will show you how many children
cell[0,1] has. On Firefox 1.5.0.10 and Opera 9.01, the popup show 5
children. On IE 6.0.2900.2180, it shows 2 children which is the
correct answer. Can anyone tell me why it's show 5 children on the
other browsers?

Because browser developers disagree on how to interpret the W3C
specification in regard to the maintenance of whitespace in the source
markup.

How can browser developers disagreed when the specification says the
preservation of non-significant white space in the DOM is optional? It
is not disagreeing to take a different choice than someone else.

<snip>

That was in February 2000. The situation hasn't changed,
I don't expect it will any time soon.

It would not now be possible for any change in the standards to either
require or preclude the preservation of non-significant white space in
a generated DOM. Far too much software has made one decision or the
other when presented with the option and declaring either one as no
longer acceptable now would not be tolerated.

>Isn't the cell at [0,1] supposed to have 2 children only,
div first and div second?

Maybe, maybe not - it depends on who you ask. ;-)

There are many correct answers, none of which are less than 2. Other
options are available in the creation of a DOM from mark-up. For
example, should the DOM be presented pre-normalised (in the sense of
having no adjacent text nodes) or not? If a DOM was required to be pre-
normalised then there would be little point in defining a - normalise
- method on the Node interface, but that does not mean they will never
be pre-normalized.

Richard.

Mar 6 '07 #5

p.lepin

On Mar 6, 12:32 pm, "Richard Cornford"
<Rich...@litotes.demon.co.ukwrote:

Other options are available in the creation of a DOM from
mark-up. For example, should the DOM be presented
pre-normalised (in the sense of having no adjacent text
nodes) or not?

I believe you are wrong on this one. The description of
Text interface in DOM Level 2 Core seems rather
uncompromising:

When a document is first made available via the DOM,
there is only one Text node for each block of text. Users
may create adjacent Text nodes that represent the
contents of a given element without any intervening
markup, but should be aware that there is no way to
represent the separations between these nodes in XML or
HTML, so they will not (in general) persist between DOM
editing sessions. The normalize() method on Node merges
any such adjacent Text objects into a single node for
each block of text.

If a DOM was required to be pre-normalised then there
would be little point in defining a - normalise - method
on the Node interface, but that does not mean they will
never be pre-normalized.

The description given above also explains why normalize()
might be useful. The remarks provided for normalize()
method itself give further explanations:

Puts all Text nodes in the full depth of the sub-tree
underneath this Node, including attribute nodes, into a
"normal" form where only structure (e.g., elements,
comments, processing instructions, CDATA sections, and
entity references) separates Text nodes, i.e., there are
neither adjacent Text nodes nor empty Text nodes. This
can be used to ensure that the DOM view of a document is
the same as if it were saved and re-loaded, and is useful
when operations (such as XPointer [XPointer] lookups)
that depend on a particular document tree structure are
to be used.

There's a well-known bug in Gecko engine that *forces* long
chunks of text to be denormalized into 4096 octets long
(defined as a preprocessor constant, and I've seen the
darned thing with my own eyes, too) text nodes. It's been
around for four years at least I believe, and the number of
cardiac arrests it caused is probably counted in dozens,
but the dev team refuses to fix it quoting performance
reasons. The fact that the bug exists and that we've
learned to live with it doesn't yet mean it's standard
behavior, though.

--
Pavel Lepin

Mar 6 '07 #6

Thierry Lam

Thanks for the response, I thought I was going crazy with those
anomalies.

On Mar 6, 6:23 am, p.le...@ctncorp.com wrote:

On Mar 6, 12:32 pm, "Richard Cornford"

<Rich...@litotes.demon.co.ukwrote:
Other options are available in the creation of a DOM from
mark-up. For example, should the DOM be presented
pre-normalised (in the sense of having no adjacent text
nodes) or not?

I believe you are wrong on this one. The description of
Text interface in DOM Level 2 Core seems rather
uncompromising:

When a document is first made available via the DOM,
there is only one Text node for each block of text. Users
may create adjacent Text nodes that represent the
contents of a given element without any intervening
markup, but should be aware that there is no way to
represent the separations between these nodes in XML or
HTML, so they will not (in general) persist between DOM
editing sessions. The normalize() method on Node merges
any such adjacent Text objects into a single node for
each block of text.

If a DOM was required to be pre-normalised then there
would be little point in defining a - normalise - method
on the Node interface, but that does not mean they will
never be pre-normalized.

The description given above also explains why normalize()
might be useful. The remarks provided for normalize()
method itself give further explanations:

Puts all Text nodes in the full depth of the sub-tree
underneath this Node, including attribute nodes, into a
"normal" form where only structure (e.g., elements,
comments, processing instructions, CDATA sections, and
entity references) separates Text nodes, i.e., there are
neither adjacent Text nodes nor empty Text nodes. This
can be used to ensure that the DOM view of a document is
the same as if it were saved and re-loaded, and is useful
when operations (such as XPointer [XPointer] lookups)
that depend on a particular document tree structure are
to be used.

There's a well-known bug in Gecko engine that *forces* long
chunks of text to be denormalized into 4096 octets long
(defined as a preprocessor constant, and I've seen the
darned thing with my own eyes, too) text nodes. It's been
around for four years at least I believe, and the number of
cardiac arrests it caused is probably counted in dozens,
but the dev team refuses to fix it quoting performance
reasons. The fact that the bug exists and that we've
learned to live with it doesn't yet mean it's standard
behavior, though.

--
Pavel Lepin

Mar 6 '07 #7

On Mar 6, 1:32 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

How can browser developers disagreed when the specification says the
preservation of non-significant white space in the DOM is optional?

That is the exact problem in describing the phenomemon in public
access sources (Wikipedia, Mozilla MDC wiki etc.)
The group of phantom nodes supporters wants any mention to be in the
form "Any standard compliant user agent...", "As required by W3C
specifications..." - other words they want a reference to a strong
standard endorsement in each and every description. Anything without
such statement is called bias, contested, moved to talk section or
removed all together - until the next rollback. See for instance
firstChild MDC article to get a feel.

Mar 7 '07 #8

Different number of children in IE, Firefox and Opera

This discussion thread is closed

Similar topics