Re: Mutation events replacement

On 21/07/11 6:18 AM, David Flanagan wrote:
> On 7/20/11 12:11 PM, Ryosuke Niwa wrote:
>> On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor 
>> <Simetrical+w3c@gmail.com <mailto:Simetrical%2Bw3c@gmail.com>> wrote:
>>
>>     On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan
>>     <dflanagan@mozilla.com <mailto:dflanagan@mozilla.com>> wrote:
>>     > Finally, I still think it is worth thinking about trying to
>>     model the
>>     > distinction between removing nodes from the document tree and
>>     moving them
>>     > (atomically) within the tree.
>>
>>     I'll chip in that I think this is useful.  It makes things somewhat
>>     more complicated, but remove/insert and move are conceptually very
>>     different.
>>
>>
>> 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.
>
> If you get a mutation event that says that node A was removed from 
> node B and inserted into node C, you know nothing about the state of 
> node A, since it could have been mutated while it was outside of the 
> tree and no mutation events would have been recorded.  Its attributes, 
> text and children all could have changed, so the mutation listener has 
> to basically discard everything it knows about node A and treat it as 
> a brand-new node.
>

Under Jonas' original proposal, mutation listeners would be called for 
nodes that are outside the document (the API would be available on 
Document, Element and DocumentFragment interfaces).

As long as you add listeners to node A before it is removed from node B 
you can be informed of mutations on (or below) node A before it is 
inserted into node C.

Of course, the optimal place to add a listener to node A is in a 
synchronous mutation listener that is fired when node A is removed. In 
the case of asynchronous mutation listeners a better solution might be 
to have the API on the Document interface and use an approach similar to 
event delegation.