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

Re: Mutation events replacement

From: David Flanagan <dflanagan@mozilla.com>
Date: Wed, 20 Jul 2011 13:34:55 -0700
Message-ID: <4E273BEF.4070200@mozilla.com>
To: public-webapps@w3.org
On 7/19/11 4:01 PM, Jonas Sicking wrote:
> 'listener' above would be a function which receives a single argument
> when notifications fire. The value of this argument would be an Array
> which could look something like this:
>
> [ { 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] } ]
>
>
Given that childlist and attribute changes are merged together into 
arrays, there is, in general, no way to reconstruct the ordering of 
mutations.  In the example above, I'd assume that the first change to 
node1 occurred before the change to node 2.  But there are 8 other 
changes to node1 and we know nothing about their ordering relative to 
the others.

So, if mutation order is not preserved, is an array the right data 
structure for this unordered set of mutations?  There is a Map type 
proposed for ES.next that allows objects as keys: 
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets  
Would it be helpful to use that as the basis of this data structure?  Or 
could DOMCore define a NodeMap type (to go along with NodeList?)

I don't have a specific use-case in mind, but I wanted to bring this up 
since I imagine it would be nice to be able to quickly find all 
mutations for a given target node without having to do a linear search 
with Array.filter() or similar.

     David
Received on Wednesday, 20 July 2011 20:35:33 GMT

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