RE: Mutation events

Jonas Sicking wrote:
> Cameron McCormack wrote: 
> > Boris Zbarsky: 
> >> Right.  Olli is talking about the slowdown when an 
> >> operation there is a listener for happens.  So if 
> >> you're listening for DOMAttrModified, any attribute 
> >> change (including foo.style.* changes). 
> > 
> > Could a solution to this be to allow listeners to be 
> > registered (somehow; the DOM Events model doesn't 
> > support this at the moment) for particular attributes? 
> 
> That would help with modifications to other attributes, 
> sure, but it wouldn't help with modifications to the 
> attribute for which there are listeners. 
> 
> It also wouldn't help with any other DOM mutations (e.g. 
> inserting and removing children). 

Many applications using mutation events will be receiving
more events than they are interested in, and will have to
do their own "filtering" to find the interesting events.
Cpu cycles will be wasted both in browser implementation 
and page scripts dealing with these unwanted events.

I agree with Cameron that it sounds interesting to be able
to specify/filter events on a finer level already when 
subscribing to them.
If we assume that we were able to specify this filtering in 
some general way for all mutation types, would this make
enough difference in performance to be an interesting
option?

And if the answer above is yes, could the general 
mechanism for specifying filters be based on CSS selectors 
and find synergies with querySelectorAll in the Selectors 
API?

Best regards
Mike Wilson

Received on Sunday, 10 May 2009 11:39:20 UTC