- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 30 Jun 2012 19:20:46 +0200
- To: Rafael Weinstein <rafaelw@google.com>
- Cc: Adam Klein <adamk@chromium.org>, olli@pettay.fi, Anne van Kesteren <annevk@annevk.nl>, Ian Hickson <ian@hixie.ch>, WebApps WG <public-webapps@w3.org>
On Sat, Jun 30, 2012 at 5:56 PM, Rafael Weinstein <rafaelw@google.com> wrote: > On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein <adamk@chromium.org> wrote: >>> On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote: >>>> >>>> All in all I think that as soon as we introduce exceptions to when >>>> MutationObserver callbacks fire we change the API from being a >>>> reliable way to track DOM mutations to a unreliable way where all >>>> callers have to be aware of exceptions and deal with them in other >>>> ways. I.e. it feels like it significantly reduces the value of >>>> MutationObservers. >>>> >>>> And so far I don't see any good arguments made for making that >>>> reduction in value. Did I miss any arguments other then the randomness >>>> argument? >>> >>> >>> Performance was one concern that's come up in discussing this with Ojan and >>> Rafael. Imagine a MutationObserver attached to the document near the top of >>> the page. Now we need to create basically one MutationRecord per node >>> inserted (because the parser operates in a depth-first sort of order). I'm >>> not at all sure this is a show-stopper (we might be able to introduce some >>> new MutationRecord type that could compactly represent parser-style >>> operation), but it definitely seems worrisome, especially given that one of >>> the common uses for MutationObservers is extensions which might run on many >>> (all?) pages. >> >> Hmm.. is there actually anything requiring that nodes are inserted one >> at a time? Internally in mozilla we do insert nodes one at a time, but >> the notifications we send out to the various subsystems make it seem >> like nodes are inserted in big chunks. This has previously been to > > Are the chunks arbitrarily shaped fragments? I.e. is their any > restriction on their shape other than "a tree"? We only perform valid DOM operations, which means that we're restricted to mutating Text nodes and inserting things that a DocumentFragment can express. I.e. we only consecutive siblings, though these siblings can have arbitrarily big subtrees. So if we're parsing a document like: <div> <p> <span>...lots of nodes here...</span> <span>...more content here...</span> </p> <form>...lots of nodes here...</form> <footer>...enough with the content already...</footer> </div> and a network boundary falls after the start <p> tag, then we'll first do a single insertion which looks like <div> <p></p> </div> then once we receive more content we'll do a single insertion containing the two <span> elements: <div> <p> <span>...lots of nodes here...</span> <span>...more content here...</span> </p> </div> then do a single insertion containing the form and the footer <div> <p> <span>...lots of nodes here...</span> <span>...more content here...</span> </p> <form>...lots of nodes here...</form> <footer>...enough with the content already...</footer> </div> So all in all 3 MutationObserver records would be created in this instance. / Jonas
Received on Saturday, 30 June 2012 17:21:44 UTC