Re: Mutation events replacement

On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay <> wrote:
> On 07/04/2011 07:28 PM, Ojan Vafai wrote:
>> Apologies in advance if my comment makes no sense. This is a long
>> thread, I tried to digest it all. :)
>> On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky <
>> <>> wrote:
>>    That may be ok, if the use cases that incur this cost are rare and
>>    the common case can be better served by a different approach.
>>    Or put another way, if 1% of consumers want the full list because it
>>    makes them 4x faster and the other 99% don't want the full list, and
>>    the full list is 3x slower for the browser to build than just
>>    providing the information the 99% want, what's the right tradeoff?
>> I'm not sure there really is a performance tradeoff. I believe that the
>> proposal Rafael put forward should almost always be faster. Storing the
>> list of changes and doing a JS callback once, for nearly all use-cases,
>> should be faster than frequent, semi-synchronous callbacks.
>> The only bit that might be slower is what data you include in the
>> mutation list. I believe that all the data you'd need is cheap except
>> for possibly the following two:
>> -The index of the child that changed for ChildListChanged (is this
>> actually expensive?)
> You may need more than just an index. element.innerHTML = null removes
> all the child nodes.
> And element.inserBefore(some_document_fragment, element.lastChild)
> may insert several child nodes.
> Depending on whether we want to get notified for each mutation
> or batch the mutations, simple index may or may not be enough.

Would a node reference be better ("nextSibling")?  Assuming the
listeners have access to all inserted/removed nodes along the way,
using another as an anchor seems like it would work properly (though
the innerHTML case may need something special).

>> -The old value of an attribute/text node. I know this is expensive in
>> Gecko's engine at least.
> Shouldn't be that slow.
> Mutation listener could easily
> implement old/new value handling itself, especially if it knows which
> attributes it is interested in.

This only works if listeners don't care about intermediate values,
since all they'll have access to is the last value they saw and the
current value in the DOM. If it was set several times during a single
"mutation event" (whether that be your or Rafael's definition of a
"transaction"), they'll miss those in-between values.  Also, while
this would be acceptable for some use cases, the editing/undo use case
would need to keep values of all attributes at all nodes, which seems
likely to be worse than having the UA take care of this.

>> I'd be fine with excluding that information by default, but having a
>> flag you pass at some point saying to include those. That way, only
>> sites that need it take the performance hit.

Given that different use cases seem to have wildly different
requirements (some probably only care about one or two attributes
while others care about the entire document), this approach to
handling the availability of oldValue/newValue is appealing.

- Adam

Received on Tuesday, 5 July 2011 11:56:56 UTC