- From: Rafael Weinstein <rafaelw@google.com>
- Date: Fri, 1 Jul 2011 17:36:50 -0700
- To: David Flanagan <dflanagan@mozilla.com>
- Cc: Ryosuke Niwa <rniwa@webkit.org>, Olli@pettay.fi, Olli Pettay <Olli.Pettay@helsinki.fi>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
On Fri, Jul 1, 2011 at 4:15 PM, David Flanagan <dflanagan@mozilla.com> wrote: > On 7/1/11 4:09 PM, Ryosuke Niwa wrote: > > On Fri, Jul 1, 2011 at 3:47 PM, Rafael Weinstein <rafaelw@google.com> wrote: >> >> If you want to discover mutations to nodes while outside the tree, >> then having a single subtree observer isn't sufficient. You'll need an >> attribute observer registered on all elements reachable from the root. >> I believe this is the same with both proposals. > > I don't think that's what he meant. He's saying that it's useful to > distinguish a node that's been removed from the document in order to insert > it to somewhere else (i.e. the node was attached to the document prior to > the insertion) from a node that was not attached to the document prior to > the insertion. > - Ryosuke > > Yes, that's mostly what I meant. > > It looks like I responded off-list to Rafael when I meant to do a reply all. > Here's what I said: > > I'm not trying to discover mutations on nodes outside the tree. I'm trying > to explain why you cannot correctly model node moves with pairs of > remove/insert mutation events. > > Note that when I say "move" I only care about the case where appendChild or > insertBefore() is called on a node that is already in the document. > > David > Apologies if I'm not understanding. In your example, it looks like the problem you're pointing to is that the move isn't the *only* thing that happened (the title data was also changed). Is that right? We've been prototyping more useful higher-level semantics on top of what we've proposed (akin to what you're asking about). In general, if you want to know something correct about what happened to a tree from state (a) to state (b) you need to register an observer at all nodes in the tree for the types of changes you care about. Subtree observation isn't sufficient for this purpose exactly for the reason you are observing: you don't hear about when something that was in tree was removed, modified, then returned. We've prototyped the semantics of our proposal and are working on implementing higher-level observation semantics on top of them. It's still work in progress, but you can get an idea of what's required. For example, Document.observeElement(tagName) is implemented here: http://code.google.com/p/mdv/source/browse/trunk/platform/dom_observe.js#30 With the interesting algorithm described here: http://code.google.com/p/mdv/source/browse/trunk/platform/dom_observe.js#299 observeElement reports when an element entered the tree or left the tree, and tolerates any combination of intermediate mutations: http://code.google.com/p/mdv/source/browse/trunk/platform/dom_observe_test.html#205
Received on Saturday, 2 July 2011 00:37:15 UTC