[webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)
andreas.delmelle at telenet.be
Fri Jun 18 10:27:13 PDT 2010
On 17 Jun 2010, at 20:37, Alexey Proskuryakov wrote:
> 17.06.2010, в 9:53, Andreas Delmelle написал(а):
>> If WebKit chooses, for example, to ignore character events from the parser in nodes where logically it doesn't make sense to have stray characters
> That would break e.g. Web sites where JS accesses DOM in ways such as node.firstChild.nextSibling, or node.childNodes. We've previously seen similar breakage happen after changing WebCore parsing code.
Wow, good point! Suddenly I feel foolish, not having thought of that hyper-trivial scenario. Obviously a very good reason to keep those nodes in.
Still, one wonders from time to time how much bandwidth is actually wasted by sending over all these extraneous bytes that ultimately compel JS developers to write code like the above. I don't think I have ever seen a website that does /not/ serve its HTML pretty-printed... That seems like an awful lot of spaces, tabs and linefeeds!
On the other hand, node.firstChild.nextSibling just seems like asking for trouble. One could argue that people who do use that to get to the first element node do not need to be accommodated. It would suffice for one of the page's authors to insert a small comment node to break that code.
One could just as easily extend Node with a firstElement() method that would work under all circumstances --but, oh yes, IE didn't support that back then... ;-)
More information about the webkit-dev