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

On Nov 27, 2008, at 00:19, Boris Zbarsky wrote:

> Henri Sivonen wrote:
>> Why is there even a need for parsing into a document fragment?
>
> In Gecko's case, because there is an existing (and used) API that  
> hands back document fragments...  So that needs to be supported,  
> though it could just share code with innerHTML instead of innerHTML  
> being implemented in terms of createContextualFragment as now.  That  
> said,

In Gecko, a fragment seems to be nsIContent, too, so it should be easy  
to put a document fragment into slot 0 of the stack of the tree builder.

>> Would mutation events or something of that nature go wrong if  
>> parsing directly into the context node?
>
> Well, they'd fire as you insert nodes, yes.

Do you mean when the parser inserts node or when a document fragment  
is inserted into the context node?

I'm doing things like aParent->AppendChildTo(aChild, PR_TRUE); with  
the assumption that this notifies but doesn't fire a mutation event.  
Now that I've looking further in the code, I'm suspecting the two  
might be coupled...

> Right now by the time that happens the parser is done and we're just  
> in the already-solved case of inserting a document fragment into a  
> document.  So there are just fewer codepaths, from the DOM point of  
> view (though possibly more from the parser's).

Are different browsers consistent in what mutation events they fire in  
this case?

> From a spec point of view the only obvious issue I see here is that  
> the mutation event behavior means the parser needs to take pains to  
> produce the same results as would be produced by the currently- 
> specified algorithm even in cases when mutation events rearrange the  
> DOM.


Can mutation event listeners do any kind of mischief before there has  
been an event loop spin?

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

Received on Thursday, 27 November 2008 10:17:25 UTC