Re: Mutation events replacement

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