W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: David Flanagan <dflanagan@mozilla.com>
Date: Tue, 19 Jul 2011 22:43:14 -0700
Message-ID: <4E266AF2.9040408@mozilla.com>
To: public-webapps@w3.org
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.

     David
Received on Wednesday, 20 July 2011 05:43:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT