- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Thu, 27 Nov 2008 12:16:36 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: HTML WG <public-html@w3.org>
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