- From: David Flanagan <dflanagan@mozilla.com>
- Date: Wed, 20 Jul 2011 13:34:55 -0700
- 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 UTC