Re: Mutation events - slowness examples

On 6/25/09 5:04 AM, Sergey Ilinsky wrote:
>> In conclusion, I think the data presented shows the performance
>> characteristics of mutation events to be unacceptable in current browsers
>> to endorse them as a common technique.
>>      
>
> 1) Unacceptable performance characteristics and unreasonable UI slowdown caused
> There are many ways to slow down a browser and hence end user experience besides using Mutation Events (including those not requiring scripting at all, but solely using CSS, SVG etc)
> Developers do use these and many other ways, also because popular JS libraries promote those ways - both in practices and inefficient implementations
>
> 2) Endorsing Mutation Events as a common technique
> I think this will hardly happen. First because there is very tiny amount of developers who know Mutation Events exist, and a lesser amount of those who understand what they could/should be used for. Second, because there are simply no sensefull use cases (on the web) for them (see an earlier attempt to define on them)
>
>    

Hi Sergey,

Apologies if this is old news but I'm not sure what earlier attempt you 
are referring to.

One potential use case is coming via WAI-ARIA:
http://www.w3.org/WAI/PF/aria-practices/#focus_activedescendant

I'm not a big proponent of this; just noting it as a use case. The idea 
is that modifications to the aria-activedescendant attribute 
(DOMAttrModified) are expected to be handled by the web developer, and 
the visual appearance of focus to be restyled. Related exploration I did 
for the W3C is here: 
http://david.atrc.utoronto.ca/exploratory/w3c/writable-activedescendent.html

I used browser sniffing instead of feature detection so that it self 
documented to my audience the state of browser support.

cheers,
David