[webkit-dev] Why so many text nodes in the DOM? (especially ones with just whitespace)

[Eric Seidel]

firstElementChild already exists in modern browsers:
http://www.w3.org/TR/ElementTraversal/#interface-elementTraversal

Anyway, this thread is done.

On Fri, Jun 18, 2010 at 10:27 AM, Andreas Delmelle
<andreas.delmelle at telenet.be> wrote:
>
> 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[3]. 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... ;-)
>
>
> Regards,
>
> Andreas Delmelle
> ---
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>