On 07/02/2011 12:59 AM, David Flanagan wrote:
On 7/1/11 2:06 PM, Rafael Weinstein wrote:
On Fri, Jul 1, 2011 at 12:43 PM, David Flanagan<dflana...@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?
Sure they are. If the node has listeners, they will get called.
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
