childNodes.leng th IE and FF difference

[Q1tum]

Hi all,

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

<?xml version="1.0" encoding="ISO-8859-1"?>
<guestbook>
<entry>
<from>Q1tum</from>
<mail>kuukeleku u at gmail dot com</mail>
<date>2006-05-16 09:41</date>
<message>Firs t test message</message>
</entry>
<entry>
<from>Q1tum</from>
<mail>kuukeleku u at gmail dot com</mail>
<date>2006-05-17 09:41</date>
<message>Second e test message</message>
</entry>
</guestbook>

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

var xml = response.respon seXML;
var table = document.getEle mentById('guest book');

var num = xml.getElements ByTagName('gues tbook')[0].childNodes.len gth;

alert(num);

IE alerts 2
FF alerts 5

Anyone have a idea why that is?

Regards,

Q1tum

[Ian Collins]

Q1tum wrote:

Hi all,

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

<?xml version="1.0" encoding="ISO-8859-1"?>
<guestbook>
<entry>
<from>Q1tum</from>
<mail>kuukeleku u at gmail dot com</mail>
<date>2006-05-16 09:41</date>
<message>Firs t test message</message>
</entry>
<entry>
<from>Q1tum</from>
<mail>kuukeleku u at gmail dot com</mail>
<date>2006-05-17 09:41</date>
<message>Second e test message</message>
</entry>
</guestbook>

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

var xml = response.respon seXML;
var table = document.getEle mentById('guest book');

var num = xml.getElements ByTagName('gues tbook')[0].childNodes.len gth;

alert(num);

IE alerts 2
FF alerts 5

Anyone have a idea why that is?

The whitespace between tags?

FF is seeing <textnode><entr y><textnode><en try><textnode>

Check the child node types.

--
Ian Collins.

[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]

Q1tum wrote:

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.

--
Ian Collins.

[VK]

Ian Collins wrote:

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.mozill a.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<foo
<bar
</bar
</foo
</foobar>

[VK]

VK wrote:

See <https://bugzilla.mozill a.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.or g/articles/2005/11/11/bug-26179-mozilla-reports-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]

VK wrote:

Ian Collins wrote:

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.mozill a.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.

--
Ian Collins.

[Michael Winter]

On 17/05/2006 12:16, VK wrote:

Ian Collins wrote:

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,

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

><foo
><bar
></bar
></foo
</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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Ian Collins]

Michael Winter wrote:

On 17/05/2006 12:16, VK wrote:

Ian Collins wrote:

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,

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.

--
Ian Collins.

[RobG]

Ian Collins wrote:

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).
--
Rob
Group FAQ: <URL:http://www.jibbering.c om/faq/>