Re: Tree construction: Coalescing text nodes

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. If you start manually 
manipulating the DOM via scripting I'd expect to end up with the DOM I 
created (e.g., if I appendChild a text node I would expect a text node 
to be appended, I wouldn't expect, ever, to get a single text node if 
there was already a text node as the last child). However, the 
document.write() case is quite possibly an interesting matter… That 
said, if we take that document.write() just adds stuff to the input 
stream then I'd expect to get no adjacent text nodes through that either.

> Part of the issue here is how much it costs in performance to always inspect the DOM for a pre-existing text node sibling (as opposed to the parser trying to coalesce only in cases where the parser itself knows it may have left an adjacent text node in the tree).
> 
> (I don't know if the perf cost matters.)

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), 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 think seeming that the perf issue was never raised before the spec was 
changed to require adjacent text nodes (only the plausibility of 
immutable strings and O(n^2) coalescing) should make it not an overly 
large concern against moving back to the old text.

-- 
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Received on Friday, 13 November 2009 12:16:20 UTC