Re: Mutation events replacement

On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> > 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?


But if you have the full list of mutations that had happened, you should be
able to infer exactly where nodes and inserted and removed.  I'm thinking of
cases where collaborative editing app and so forth needs to sync data with a
remote server.  In that case, the script wants to figure out what inserted
or removed where.

>> * 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.
>

Agreed.

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.
>

Yeah, that sounds like a reasonable approach here.  I'll think about use
cases where we want after-value.

I'm kind of guessing what editor authors want to have from my limited
experience getting feedbacks from them but I'll contact folks I know and see
if I can get more concrete use cases.

- Ryosuke