Cleaning useless whitespace in Mozilla DOM

[beetle]

Originally posted by WA
Is there a logic behind Mozilla/NS inserting whitespaces into a document in such a manner? It seems to accomplish nothing but complicate matters.

Well, jkd will tell you that it's nice because it 'preserves' the code format. Although this is true, I have serious reservations about how 'useful' that actually is.

[jkd]

1. It is correct.

2. It preserves the format of the code. IE mangles all code it parses. Mozilla doesn't. This is useful when utilizing future DOM3 Load and Save modules to dynamically load or generate XML files. You'll be assured that the structure isn't modified from the original one you loaded.

3. It is not any harder to deal with if you are expecting it.

[beetle]

1. Agree

2. Agree, but not a concern to me now.

3. Disagree. Doable, yes. Just as easy? No, because it takes extra time to figure out where these textnodes are going to show up, and just for that time commitment it becomes 'harder' (for lack of a better word) I mean, Vladdy wrote an entire script just to help him solve these sort of inconsistencies. His tool makes dealing with this easier, but knowledge of the problem does not make it 'just as easy'

<div id="parent" onClick="alert(this.childNodes[1]);">
<span id="child1">text</span>
<span id="child2">text</span>
</div>

As far as I'm concerned, the above reference should ALWAYS find span#child2, regardless of whether or not there are valid (albeit empty) textNodes there. References like the one above should obey the structure of the HTML objects and valid textNodes but ignore 'empty' ones. In short, I'd rather not have to strip them out...It would be nice if Gecko would recognize them only when it's necessary or requested (such as the Save and Load interface you speak of)

[jkd]

I find it interesting that in IE, the Adobe SVG Plugin also parses indentation as empty text nodes. This leads me to prefer the idea of parsing them, because you have two separate XML parsers found in web browsers (the Adobe SVG one, and expat in Mozilla) that agree, as opposed to just one (MSXML in IE) that doesn't.

And expat is basically an industry standard, and is accessible in most scripting languages, and C/C++. And as forementioned, Mozilla also uses expat.

[WA]

When it comes to technologies, IE historically seems to have been more about ease of use and dare I say, practicality, while NS likes to take the more extreme route, whether in NS4 (extremely poor), or NS6 (extremely rigid in its application of standards). I don't want to argue which is better, though I will say getting rid of all those white spaces can become an agitating and resource hogging task. And as beetle says, unless one has a thorough understanding of the document tree, the task can also be unpredictable. IE's treatment of the document is more inline with logical thinking.

[jkd]

Originally posted by WA
I will say getting rid of all those white spaces can become an agitating and resource hogging task.

Then don't get rid of them, and expect a more standard XML parser from IE.

[Alex Vincent]

Originally posted by WA
Is there a logic behind Mozilla/NS inserting whitespaces into a document in such a manner? It seems to accomplish nothing but complicate matters.

http://bugzilla.mozilla.org/show_bug.cgi?id=26179

This bug has a very lengthy debate on whitespace text nodes in XML. Basically, mozilla.org believes there is no justification in a generic XML document to remove whitespace.

I agree with them: the duty of removing whitespace should be placed on the webpage author. Which is why I wrote the script.

Here's a lengthier article on the subject:

http://mozilla.org/docs/dom/technote/whitespace/

[beetle]

Good reading, Alex. Thanks for that. I like what this person had to say...

------- Additional Comment #3 From lhylan 2000-05-31 23:58 -------
I'm reopening this one because the more I think about it, the more I think exposing whitespace as a text node is the wrong thing to do. Why? Because you can't do it consistently. Text nodes are invalid in between table rows and table cells, for example -- so the same newline that appears after a </td> cannot be represented as a text node the way it can be if it appears after a </p>. This harms the roundtripping argument, IMHO. Also, it seems to me that whitespace shouldn't affect the structure of a document; I consider an HTML document with no linebreaks to be structurally identical to one with all kinds of whitespace between tags. If newlines are represented as text nodes, the two documents would be structurally different.

[whammy]

Ok.. say I use 5 spaces instead of a tab character when I code. Since many EDITORS screw up tabs. And I use a Line Feed character as the (standard XML) return character.

Good?

It's not only annoying, but if another developer uses tabs, the resulting code can be practically unreadable due to differences in text editors.

Sorry not exactly on topic...

[beetle]

Differences in text editors? I don't get that....

Maybe you mean difference in settings. In every text-editor I've worked with you can specify the size of your tabulation...for example...this forum uses 8-length tabs for the CODE tags, but both my text-editor and Dreamweaver use 4-length tabs....

So, if I want something to post here identical to how i see it in my editor, I need to change my tab setting to 8.

is that what you mean?

[whammy]

Yeah... exactly. If they're different, and you don't use spaces, I've seen some code that looks perfectly formatted in one developer's editor end up looking like:

This
        is
      some
                  formatted

             code
                                       but
    it's
 messed
                      up!

that ^ in mine (and others).

[beetle]

Whammy...

I see your point...but using spaces almost exponentially adds to the filesize. At times this can be negligible, othertimes not. If you substituted every tab for five spaces in some code, you could increase filesize significantly.

The data is the same from screen to screen, only the output is different. The fundamental makeup of the code should NOT have to be changed to accomodate everyone's editor. Try this, I do it on any project that I know is gonna be shared or dispersed...at the top of the page...

<!-- This document is best viewed if you set your tab-spacing to 4 -->

Or something similar.

[beetle]

Man oh man oh man. How did I (and so many people here) miss the normalize() method? I did a search (here, at sitepoint AND webxpertz) and came up with nothing on this method. No-one is talking about it.

Now, from my preliminary testing, this method doesn't remove visibly intruding textNodes like the functions in this post do, but any reference you make (firstChild, parentNode, etc) after enacting normalize() will grab the expected node, and not any intermediary textNode.

Again, wow. This makes my life easier

normalize() @
MSDN
mozilla.org
W3C

[jkd]

I was unsure if normalize() normalized the immediate child nodes of the node it is called on, or all child nodes within the depth of the subtree.

document.documentElement.normalize()

if it works on the entire subtree.

[beetle]

My tests thus far indicate it normalizes all child nodes within the subtree.