childNodes.length IE and FF difference

[Q1tum]

Hi all,

I got a problem with childNodes.length, I use the following XML for my
guestbook:

<?xml version="1.0" encoding="ISO-8859-1"?>
<guestbook>
<entry>
<from>Q1tum</from>
<mail>kuukelekuu at gmail dot com</mail>
<date>2006-05-16 09:41</date>
<message>First test message</message>
</entry>
<entry>
<from>Q1tum</from>
<mail>kuukelekuu at gmail dot com</mail>
<date>2006-05-17 09:41</date>
<message>Seconde test message</message>
</entry>
</guestbook>

when I use the following script to check I get different output in IE
and FireFox:

var xml = response.responseXML;
var table = document.getElementById('guestbook');

var num = xml.getElementsByTagName('guestbook')[0].childNodes.length;

alert(num);

IE alerts 2
FF alerts 5

Anyone have a idea why that is?

Regards,

Q1tum

 

[Ian Collins]

Hi all,

I got a problem with childNodes.length, I use the following XML for my
guestbook:

<?xml version="1.0" encoding="ISO-8859-1"?>
<guestbook>
<entry>
<from>Q1tum</from>
<mail>kuukelekuu at gmail dot com</mail>
<date>2006-05-16 09:41</date>
<message>First test message</message>
</entry>
<entry>
<from>Q1tum</from>
<mail>kuukelekuu at gmail dot com</mail>
<date>2006-05-17 09:41</date>
<message>Seconde test message</message>
</entry>
</guestbook>

when I use the following script to check I get different output in IE
and FireFox:

var xml = response.responseXML;
var table = document.getElementById('guestbook');

var num = xml.getElementsByTagName('guestbook')[0].childNodes.length;

alert(num);

IE alerts 2
FF alerts 5

Anyone have a idea why that is?

The whitespace between tags?

FF is seeing <textnode><entry><textnode><entry><textnode>

Check the child node types.

 

[Q1tum]

Hmm, I checked that before becouse I found that issue on the forums,
then it was showing me the same result.....

I just tried it again and now it is working correctly :s

Strange but thanks, it works when I enter the XML with no linebreaks

 

[Ian Collins]

Hmm, I checked that before becouse I found that issue on the forums,
then it was showing me the same result.....

I just tried it again and now it is working correctly :s

Strange but thanks, it works when I enter the XML with no linebreaks

FF is correct, the whitespace should included. Probably IE applies HTML
rather than XML rules when parsing your XML and strips the extraneous
whitespace.

 

[VK]

FF is correct, the whitespace should included. Probably IE applies HTML
rather than XML rules when parsing your XML and strips the extraneous
whitespace.

FF is wrong, no one of XML/HTML specs requires to reflect source code
pretty-print in the DOM tree. Even W3C did not reach yet such level of
idioticy. That was an original wrong reading of very badly written W3C
specs, and now it will be a painful process of admitting and correcting
it I'm affraid.

See <https://bugzilla.mozilla.org/show_bug.cgi?id=26179> for the
general discussion about the phantom nodes bug.

For the time being OP can use one of numerous tree walkers learned to
skip on phantom nodes; or use the special phantom nodes bug adjusted
pretty-print like:

<foobar

 

[VK]

See <https://bugzilla.mozilla.org/show_bug.cgi?id=26179> for the
general discussion about the phantom nodes bug.

You also can read/add some to the blog at
<http://laughingmeme.org/articles/20...ts-existence-of-phantom-text-nodes-in-the-dom>

That is a real war "Web developers vs. Firefox developers" going for
more than one year already. So instead of add some nasties about the
phantom nodes, you can join to the opposite camp (if you like to be
sadomasohistic or if you indeed manage to find some reason in their
reasonnings).

 

[Ian Collins]

FF is wrong, no one of XML/HTML specs requires to reflect source code
pretty-print in the DOM tree. Even W3C did not reach yet such level of
idioticy. That was an original wrong reading of very badly written W3C
specs, and now it will be a painful process of admitting and correcting
it I'm affraid.

See <https://bugzilla.mozilla.org/show_bug.cgi?id=26179> for the
general discussion about the phantom nodes bug.

Interesting, my interpretation of the specs was that the extraneous
whitespace should be included unless the document's schema or DTD
excluded PCDATA as a child element.

 

[Michael Winter]

FF is wrong,

It just never seems to occur to you that you are, more often than not.

no one of XML/HTML specs [...]

With regard to white space, XML and SGML differ.

In section 2.10, of the XML specification, it states quite clearly:

An XML processor must always pass all characters in a document
that are not markup through to the application. A validating
XML processor must also inform the application which of these
characters constitute white space appearing in element content.

As Firefox doesn't typically use a validating XML processor, white space
in element content will be treated simply as character data, and the DOM
Core Level 2 specification states in the introductory section, "What the
Document Object Model is":

Note: There may be some variations depending on the parser
being used to build the DOM. For instance, the DOM may not
contain whitespaces in element content if the parser discards
them.

So, conversely, if the parser does pass on white space characters (and
we've established that it may), the document tree may contain the text
nodes that Fx includes.

With applications of SGML, the situation is different as there are rules
for collapsing white space and ignoring line terminators after start
tags and before end tags. White space in element content may also need
to be ignored, but as I don't have a copy of the SGML specification, I
couldn't say for certain.

In any case, even if it is 'fixed' in future browser versions, one still
needs cope with past and current implementations, therefore whining
about it is pointless.

[snip]

For the time being OP can use one of numerous tree walkers learned to
skip on phantom nodes;

Or write one. It's trivial.

or use the special phantom nodes bug adjusted pretty-print like:

<foobar

If you want to do something that stupid, that's your choice, but don't
recommend it to anyone else. I'm sure the OP is capable of writing a
loop in order to obtain a particular child or sibling element.

Mike

 

[Ian Collins]

FF is wrong,

It just never seems to occur to you that you are, more often than not.

no one of XML/HTML specs [...]

With regard to white space, XML and SGML differ.

In section 2.10, of the XML specification, it states quite clearly:

An XML processor must always pass all characters in a document
that are not markup through to the application. A validating
XML processor must also inform the application which of these
characters constitute white space appearing in element content.

Thanks for the reference, I was sure I'd read this somewhere.

As Firefox doesn't typically use a validating XML processor, white space
in element content will be treated simply as character data, and the DOM
Core Level 2 specification states in the introductory section, "What the
Document Object Model is":

Note: There may be some variations depending on the parser
being used to build the DOM. For instance, the DOM may not
contain whitespaces in element content if the parser discards
them.

So, conversely, if the parser does pass on white space characters (and
we've established that it may), the document tree may contain the text
nodes that Fx includes.

With applications of SGML, the situation is different as there are rules
for collapsing white space and ignoring line terminators after start
tags and before end tags. White space in element content may also need
to be ignored, but as I don't have a copy of the SGML specification, I
couldn't say for certain.

I think that's the cause of the difference, IE parses XML as HTML thus
collapses the whitespace.

 

[RobG]

Michael Winter wrote: [...]

As Firefox doesn't typically use a validating XML processor, white space
in element content will be treated simply as character data, and the DOM
Core Level 2 specification states in the introductory section, "What the
Document Object Model is":

Note: There may be some variations depending on the parser
being used to build the DOM. For instance, the DOM may not
contain whitespaces in element content if the parser discards
them.

So, conversely, if the parser does pass on white space characters (and
we've established that it may), the document tree may contain the text
nodes that Fx includes.

With applications of SGML, the situation is different as there are rules
for collapsing white space and ignoring line terminators after start
tags and before end tags. White space in element content may also need
to be ignored, but as I don't have a copy of the SGML specification, I
couldn't say for certain.

I think that's the cause of the difference, IE parses XML as HTML thus
collapses the whitespace.

Is that an excuse? I thought the HTML specification dealt with white
space from the perspective of presentation, not a DOM.

For example, some written languages require that all white space is
removed and others do not so it would be silly to remove it from the DOM
depending on the language used.

I thought that whitespace should be preserved because if CSS is to be
used to display content, you can't remove whitespace (other than
collapsing it) that might be required by CSS, so better to preserve it
and let CSS do its thing.

There is a concept of treating white space in block and inline elements
differently, but CSS block elements can become inline and vice versa, so
again at the DOM level it would be silly to remove whitespace based on a
node being a block element when it might be later changed to inline (or
some other display attribute value).

 

[RobG]

FF is wrong, no one of XML/HTML specs requires to reflect source code
pretty-print in the DOM tree.

Pretty-printing is not the reason for the text nodes, printing is not
mentioned at all in the bugzilla reference below. It is irrelevant to
display of the DOM tree in the DOM Inspector.

[...]

See <https://bugzilla.mozilla.org/show_bug.cgi?id=26179> for the
general discussion about the phantom nodes bug.

It isn't a bug[1], it's "as designed" and has been "wont fix" since
January 2002.

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

[...]

1. There is a tendency to call any disliked behaviour a bug, however I
feel that term applies to programming errors that cause behaviour
contrary to the designed behaviour.

When an application does exactly what it was designed to do, yet
contrary to what you want it to do, you should call it a design flaw.
Blaming programmers for all undesirable behaviour is unfair: where it is
the result of design, let the designers wear it.

I wish someone who actually designed the "phantom nodes" behaviour would
enter the discussion at mozilla.org and explain why that decision was
made, then the discussion might be far more focused.

 

[VK]

I wish someone who actually designed the "phantom nodes" behaviour would
enter the discussion at mozilla.org and explain why that decision was
made, then the discussion might be far more focused.

AFAIK Boris Zbarsky is the "reader" of W3C specs in order to transform
them into practical algorithms for Gecko engine. A very knowledgeable
and patient person as I can tell from his posts. Actually any other one
couldn't make the job right as his task is similar to draw practical
blue prints out of Bible's liturgies )

Still in this particular case he seems failed to read the "original
intentions" right and his "never FONTFIX no matter what" seems more an
emotion rather than a conclusion on spelled arguments. Everyone
interested is invited once again to read all arguments and
contre-arguments at:
<https://bugzilla.mozilla.org/show_bug.cgi?id=26179>

It also seems that it is wrongly precluded that VK is the initiator and
some kind of pusher of this issue. I'd like to assure everyone that I
neither filed the bug, nor numerous doublicates of this bug, nor I
initiated all blogs and discussions across the Internet. Yet I may
guess on what side (Boris Zbarsky and Fx Co or Web developers) am I

I see the Phantomists Party arguments failed (but this is what /I/ see
with my narrow mind).

The major (and seems the only one) pro-argument for phantom nodes being
the ability to dynamically switch a fragment from parsed version to
<pre> format and back and the ability to have <pre> version exactly as
it was on the server.
This kind of argument remind me an old story with OSHA (grrrrr... waw,
waw - good it's over). They issued a penalty to one well known in CA
grocery store for fire extinguisher fixed on wall on the chest level.
It was required to fix them on the level of... your pants pockets. The
reason: 1) if there is a fire in the store and 2) there is a customer
at this moment on wheelchair and 3) this customer decides to
participate in the fight with fire: then she can easily reach the
extinguisher on the wall.
IMHO the phantom node preservation based on the same weird way of
putting things together: first you construct a more than questionable
situation and than you adjust the environment for disconvenience of the
real use but in convenience of the mental construct you just did.

And the major (and seems the only one) contre-argument in order to keep
things as they are is "DOM methods are still usable after some
adjustments even with phantom nodes". Yeh, they are... specially
written tree walker will make the trick. Yet the argument "you /still/
can use it" is not a kind of argument for a UA fighting for users and
developers sympathies. Everything can be used after adjustment,
hacking, twisting around etc. Yet "you /still/ can use it" is an
arguments for potential losers, not for potential winners.

 

[VK]

Yet "you /still/ can use it" is an
arguments for potential losers, not for potential winners.

More over the requred adjustment doesn't imply a global engine change
(yesterday was A, and today is B). It can be (and was suggested several
times) to do it like with W3C Box vs. IE Box situation: Mozilla just
added -moz-box-sizing with arguments border-box, content-box and
padding-box; so now everyone can work in the box she feels the most
comfortable with (<http://www.quirksmode.org/css/box.html>).

The same way it can be an extra flag added somewhere like
-moz-preserve-phantom-nodes one could set to false (but true by
default).