473,313 Members | 1,435 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,313 software developers and data experts.

childNodes.length IE and FF difference

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

May 17 '06 #1
12 4433
Q1tum wrote:
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.

--
Ian Collins.
May 17 '06 #2
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 :)

May 17 '06 #3
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.
May 17 '06 #4
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.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<foo
<bar
</bar
</foo
</foobar>


May 17 '06 #5
VK

VK wrote:
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/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).

May 17 '06 #6
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.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.

--
Ian Collins.
May 17 '06 #7
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.
May 17 '06 #8
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.
May 17 '06 #9
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.com/faq/>
May 17 '06 #10
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.


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.
--
Rob
Group FAQ: <URL:http://www.jibbering.com/faq/>
May 17 '06 #11
VK
RobG wrote:
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.

May 18 '06 #12
VK

VK wrote:
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).

May 18 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: adam | last post by:
i'm working on a portion of a CMS that allows content-admins to browse a product list, and add individual products into the taxonomy by clicking checkboxes next to categories they might belong in....
6
by: Ron Brennan | last post by:
Good evening. <span id=fileList> <input type=hidden name=file id=file_0 value=Name/> </span> .... document.getElementById(fileList).childNodes The childNodes is giving me two children: 1)...
2
by: chuck | last post by:
Hi, I am modifying some code from here http://www.quirksmode.org/dom/domform.html I have a div 'readroot' that I clone. I change the change the id and name of the childnodes of 'readroot' to...
3
by: Q1tum | last post by:
Hi all, I have a problem with getting the amount of childs in a XML structure, the strucure is somewhat like the following: <?xml version="1.0" encoding="iso-8859-1"?> <cms> <num>21</num>...
3
by: Jake Barnes | last post by:
This weekend I decided to play around with Javascript a little and try to teach myself some things about AJAX and DOM. I've been doing experiments on this page: ...
1
by: yawnmoth | last post by:
Given an element ID, is there a way to figure out what index one would need to use in the parentNode's childNodes array to get at that element? For example... <body> <div id="parent"> <div...
5
by: Moses | last post by:
HI The Value for childNodes.length differs with mozilla and IE Is it problem with my coding..... I could not under stood............. The following is the details
2
by: windandwaves | last post by:
Hi Folk I want to add an "onClick" function to the radio boxes, but I am having trouble. Can you help me <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://...
2
by: willyWEB66 | last post by:
Hi everyone, I have this code in javascript where the XML file is loaded and displayed to an html using XSLT. It works fine in IE but not in Firefox. My problem is in the looping to the...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.