Re: Mutation events replacement

Thanks for the new proposal, Jonas.  I'm very excited about the progress
we're making towards a saner world!

On Tue, Jul 19, 2011 at 4:01 PM, Jonas Sicking <jonas@sicking.cc> 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] } ]
>
> A few things to note here:
>
> * There is only ever one entry in the array for a given target+type
> pair. If, for example, multiple changes are made to the classlist of a
> given node, these changes are added to the added/removed lists.
> * For "childlist" changes, you get the full list of which nodes were
> added and removed.
>

For editing purposes, it's also crucial to know from/to where nodes are
removed/inserted.  It seems like adding an offset trivially solves this
problem without much overhead.


> * For "attributes" changes you get a full list of which attributes
> were changed. However you do not get the new and old value of the
> attributes as this could result in significant overhead for attributes
> like "style" for example.
>

Again, it'll be very useful to have old and new values for editing purposes.
 Although I have a reservation as to whether we should do for style or not
because calling mutation listeners every time script modifies some style
property will be quite expensive as it requires serializing
CSSStyleDeclaration.

* For "characterdata" you don't get the old or new value of the node.
> We could also simply add the before/after values here as there
> shouldn't be as much serialization overhead involved.
>

For editing purposes, seeing old and new value is essential.

- Ryosuke