Re: Mutation events replacement

On 07/04/2011 08:16 PM, Adam Klein wrote:
> On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay<Olli.Pettay@helsinki.fi>  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<bzbarsky@mit.edu
>>> <mailto:bzbarsky@mit.edu>>  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).


Where would the node reference be?
What would the API look like?

-Olli



>
>>
>>> -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 Monday, 4 July 2011 20:45:51 UTC