Re: Mutation events replacement

On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/19/11 7:18 PM,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>
> 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 convinced about "without much overhead".  In general, adding an
> offset is O(N) in number of childnodes in many existing implementations....
>  that can be improved, but only at the cost of more memory or performance
> elsewhere.


That's a good point.  It should probably before/after node instead.

 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.
>>
>
> Yes, that is _exactly_ the problem.
>

Right so it should be an opt-in feature as you suggested.

- Ryosuke