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