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.fihttp://hsivonen.iki.fi/