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
