Re: Mutation events replacement

On 7/19/11 4:01 PM, Jonas Sicking wrote:
> [ { target: node1, type: "childlist", added: [a, b, c, d], removed: [x, y] },
>    { target: node1, type: "attributes", changed: ["class", "bgcolor", "href"] },
>    { target: node2, type: "characterdata" },
>    { target: node3, type: "childlist", added: [r, s, t, x], removed: [z] } ]
I don't see the advantage of having one array element per target/type 
combination.  Why not just one entry per modified node, and put all 
changes in the same object?  So the first two entries in the array above 
would become something like:

   { target: node1, nodesAdded: [a,b,c,d], nodesRemoved:[x,y], 
attributesChanged: ["class","bgcolor","href]}

> node.addMutationListener(listener, { childlist: true, attributes:
> true, characterdata: true });
Is the second argument optional?  What's the default?
> * If you call addMutationListener with the same listener multiple
> times any new "flags" are added to the existing registration. So
> node.addMutationListener(listener, { attributes: true });
> node.addMutationListener(listener, { childlist: true });
> is equivalent to
> node.addMutationListener(listener, { childlist: true, attributes: true });
This seems awkward to me, unless removeMutationListener is modified to 
take the same second argument as well so that notification type flags 
could be individually removed.

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.


Received on Wednesday, 20 July 2011 05:43:42 UTC