Re: Tree construction: Coalescing text nodes

On Nov 13, 2009, at 14:15, Geoffrey Sneddon wrote:

> Henri Sivonen wrote:
>> On Nov 13, 2009, at 12:06, Geoffrey Sneddon wrote:
>>> However, I think that such implementations are probably more important in terms of the structure of the DOM created (because they are more likely to support scripting), and as such it seems silly to have anything apart from a single text node in all cases, especially when such implementations can likely have a single text node backed by multiple strings internally.
>> It's not necessarily silly not to require browsers to coalesce in all cases. Would you make parser-inserted text nodes coalesce into script-created text nodes or parser-created older-than-previous text nodes that a script has moved around?
> 
> No, but I would expect the parser (without executing any script) to always create a DOM with no adjacent text nodes.

Of course, it doesn't matter when scripts aren't executed. :-)

> Surely the only additional time on top of the current spec is the foster parenting case (as the spec already requires coalescing text nodes in all other cases)

When the AAA moves the existing children of a node and moves them to another node, is it ever possible to get adjacent text nodes that way?

> and I doubt that is really common enough to have much of an effect on perf, so I do doubt that it really matters. (All that about perf cost, is, however, just blind guesses.)

I'm semi-inclined to make text nodes coalesce with previous parser-inserted text node if the previous parser-inserted text node would become the previous sibling of the text node being inserted. And if this is a perf problem with large text nodes, one could make the nodes not coalesce if the previous node has more text that a magic constant (appealing to the implementation-specific limits clause).

I want text node boundaries never to depend on TCP packet boundaries, I don't want to keep track if a text node was flushed and foster-parented due to a element token or due to flushing at the end of a buffer.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 13 November 2009 12:47:24 UTC