On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky <bzbar...@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