Re: Black-box equivalence of parsing fragments directly into context node

Henri Sivonen wrote:
> 
> I'm considering implementing HTML5 innerHTML setting in Gecko by using 
> the owner document of the context node as the document seen by the 
> parser and by sticking the context node as the first node on the stack 
> (but masking its name to show "html" to the tree builder in order to 
> avoid breaking the fragment algorithm assertions) and by then running 
> the fragment parsing algorithm without returning to the event loop until 
> done. The context node would be in the tree for the entire time. I'd 
> deflect attempts to add more attributes to the root node upon stray 
> <html> tag.
> 
> Is there a reason why the spec doesn't prescribe this? Why does the spec 
> specify parsing into another document first and then moving the nodes 
> over? Is what I described above not black-box equivalent to the steps 
> that the spec prescribes?

What do you mean by "masking its name to show 'html'"?

In general, looking at the innerHTML parsing algorithm, it seems like we 
should try to make it faster. Setting innerHTML is a very performance 
critical operation in many webapps so we definitely don't want to 
require things like creating new documents.

Why couldn't the spec instead say to use the ownerDocument of the 
context node (like Henri is suggesting) and parse into a 
documentFragment node? I.e. why do we need the new Document node and the 
new <html> node?

/ Jonas

Received on Wednesday, 26 November 2008 21:27:27 UTC