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

Re: Mutation events replacement

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Tue, 19 Jul 2011 16:18:31 -0700
Message-ID: <CABNRm60bT2XxoWCXrAv5bYXV_RAo2jA-7o=3nHkgLnPnstGRDw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Rafael Weinstein <rafaelw@google.com>, Olli@pettay.fi, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
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

* 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
Received on Tuesday, 19 July 2011 23:19:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC