Re: Mutation events replacement

On 7/19/11 7:18 PM, Ryosuke Niwa 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.

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

I have a related question.  If the same node is inserted and removed 
over and over again (say 100 times) in the same task, what 
notification(s) will be delivered at the end of the task?


Received on Wednesday, 20 July 2011 03:23:58 UTC