Re: Mutation events replacement

On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan <dflanagan@mozilla.com>wrote:

>  On 7/20/11 12:11 PM, Ryosuke Niwa wrote:
>
>  But internally, a node movement is a removal then an insertion.  There's
> always possibility that a node gets removed then inserted again after
> mutation observers are invoked.  Also, what happens if a function removed a
> bunch of nodes and then inserted back one of them?
>
>   My definition of moving a node atomically is taking a node that is
> already in the tree and passing it to appendChild() or insertBefore().
> Everything else is regular node removal followed by node insertion.
>

But appendChild or insertBefore can happen as a part of a larger operation.
 Then we'd end up splitting the list in half whenever we have this "move"
entry.

Also, since the existing mutation events and new API must co-exist for some
period of time, there's a chance that mutation event listeners can modify
DOM while the node is detached from the document synchronously.

If, on the other hand, there was some way for the listener to know that the
> node was moved atomically, then it would know that it hadn't missed any
> mutation events and it could retain whatever cached state it had for node A,
> changing only the parent.
>

I'm not sure if we can have a concept of atomicity in DOM.  Boris might have
a strong opinion on this.

Here's one possible way that the distinction between move and remove could
> be made.  Keep the added and removed lists of nodes exactly as they are
> now.  But when a node is moved atomically, also add it to an array of moved
> nodes.  Listeners that don't care about the move/remove distinction can just
> use the added and removed properties as in the current proposal.  But
> listeners that do care can check any added or removed node against the moved
> array to see if it was an atomic move.
>

That sounds like a reasonable compromise since it can be an opt-in feature,
and UAs probably don't have to do anything special while making the mutation
list.

- Ryosuke