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.
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'
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)
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.
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.
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.
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.
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 -->
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.