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

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