- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Jul 2011 16:56:15 -0700
- To: Ryosuke Niwa <rniwa@webkit.org>
- 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>
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> 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.
I'm not really sure how you're expecting to use indexes. Not that once
one node is removed, the index changes for all other nodes. Can you
provide a short example code demonstrating how you'd use the index?
>> * 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.
As has been previously mentioned, providing the old value comes with
significant overhead. For your usecase it seems like this is overhead
that you'll need to live with, but for many others it might not be.
We could solve this by making it configurable if you want the old
values or not. For example by having separate notification types that
contain before and after values.
Though note that providing the after-values rarely seems useful as you
can simply get them as needed from the DOM. As for childlists, the
only sane solution I can think of would be to provide what the whole
childlist looked like before modifications started.
/ Jonas
Received on Tuesday, 19 July 2011 23:57:15 UTC