Re: Mutation events replacement

On 7/6/2011 5:38 AM, Boris Zbarsky wrote:
> On 7/6/11 4:27 AM, Dave Raggett wrote:
>> How does that scale to the case where you set the observer on the
>> document or on a div element acting as a contained for content editable
>> content? If I am not mistaken you would have to keep a copy of the
>> document, or of that div element respectively, and keep it in sync with
>> all of the mutations, which sounds like a major performance hit, and
>> something you don't need to incur with the current DOM mutation events.
>
> Oh, you _do_ incur a major performance hit with current mutation 
> events if you watch attribute mutations, precisely due to the need to 
> save the pre-mutation values.  You just push the performance hit off 
> on the browser core.
>
> And before you say that it can do this more efficiently, that's only 
> true if you're interested in the previous value of _all_ attributes.  
> I realize your particular use case is.  But lots of others are not. 
> Unfortunately, the browser has no way to tell which attributes on 
> which elements the mutation event really cares about, so all mutation 
> event consumers take the same performance hit.  Which leads to the 
> common recommendation to not use attribute modification mutation 
> events at all, because, for example, they make your jQuery animations 
> dog-slow.
>
> Again, I realize this is not a problem for you because of your 
> particular use case of mirroring the entire DOM.  But let's not 
> pretend there's no performance hit now or that the performance hit 
> with a different setup would always be more than what we have now.
This is another advantage of onModelChanging or 'before' events. All of 
the previous values are available for listeners and the task of 
selecting which ones to process is left to the listener.

jjb

Received on Wednesday, 6 July 2011 14:24:10 UTC