Re: Mutation events replacement

On 7/1/11 2:06 PM, Rafael Weinstein wrote:
> On Fri, Jul 1, 2011 at 12:43 PM, David Flanagan<dflanagan@mozilla.com>  wrote:
>
>> As I see it, the test of sufficiency of set of mutation event is if you can
>> use them to mirror a document tree. And in my case I'm trying to do that
>> across a process boundary where I can't share nodes--I have to serialize
>> everything to a string or something similar.  If I call appendChild() on a
>> node that is already in the tree, that removes it from its current parent
>> and inserts it into a new parent.  If that generates a remove event and then
>> an insert event I'll end up having to completely re-serialize the node (and
>> all of its children) to re-insert it from scratch into the mirror tree.  If
>> the appendChild() generates a move event then I can simply serialize the
>> fact that an existing node has moved.  There are probably ways I could make
>> this work without a move event, but that's why I found it useful to make the
>> distinction.
> To clarify: Are you worried that it isn't possible to detect the move
> and avoid serializing the non-novel node without the "move"
> information in the underlying mutationList? Or are you concerned that
> detecting this is work and it might be good to just provide the
> information and remove the need for the observer to do that work?
>
> Your point about the sufficiency test being mirroring a tree seems
> exactly right to me. I may be missing something, but I think "move"
> isn't strictly necessary.
>
I suppose that calling appendChild() on a node that is already in the 
tree would probably be guaranteed to generate a remove event immediately 
followed by an insert event and that these two events would always be 
part of the same mutationList?  If so, and if I were listening for 
mutations on the document object (or any common ancestor of the old 
parent and the new parent of the moved node) then distinguishing a move 
from a remove seems as if (but see below) it would just be a matter of 
looking ahead to the next event in the list and no special move event is 
necessary.

Note that listeners that are not on a common ancestor of the old and new 
parent will not see both the remove and insert events and won't be able 
to distinguish move from remove in that way.  Now suppose that such a 
handler sees a remove event for a node.  It can check parentNode, and if 
that is non-null, it knows that the node was moved, or was reinserted 
somewhere as part of the same batch of mutations.  Again, it seems as if 
no move event is necessary.

But, and I think this is an interesting but,  what happens if a node is 
removed from the document, has its attributes or data or children 
changed and is then re-inserted into the document?  If the node has no 
parent when it is changed, no mutation events will be generated, will 
they?  In that case, even if I'm listening on a common ancestor and see 
a remove event immediately followed by an insert event, I can't really 
know that the node has not changed in the meantime.

(I don't suppose it would be sufficient (and efficient) to punt entirely 
on mutation event propagation and just send a list of all mutations on 
all nodes (whether inserted into the tree or not) to listeners on the 
ownerDocument would it?  Then client libraries could translate that 
firehose of mutations into something like Olli's proposal or into 
old-style DOM mutation events.)

     David

Received on Friday, 1 July 2011 22:00:21 UTC