W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

RE: Mutation events

From: Mike Wilson <mikewse@hotmail.com>
Date: Sun, 10 May 2009 13:38:31 +0200
Message-ID: <BAY116-DAV3B93017FD39851E6F51FAA4620@phx.gbl>
To: <www-dom@w3.org>
Message-ID: <00bf01c9d163$d7ee3590$0a01a8c0@mikedeskxp>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:00 GMT