W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Sean Hogan <shogun70@westnet.com.au>
Date: Fri, 08 Jul 2011 23:55:28 +1000
Message-ID: <4E170C50.80700@westnet.com.au>
To: Jonas Sicking <jonas@sicking.cc>
CC: John J Barton <johnjbarton@johnjbarton.com>, Olli@pettay.fi, Rafael Weinstein <rafaelw@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
On 8/07/11 10:21 PM, Sean Hogan wrote:
> On 8/07/11 8:28 AM, Jonas Sicking wrote:
>> On Thu, Jul 7, 2011 at 3:21 PM, John J Barton
>> <johnjbarton@johnjbarton.com>  wrote:
>>> Jonas Sicking wrote:
>>>>   We are definitely
>>>> short on use cases for mutation events in general which is a problem.
>>> 3. Client side dynamic translation. Intercept mutations and replace or
>>> extend them. This could be for user tools like scriptish or stylish, 
>>> dev
>>> tools to inject marks or code, or for re-engineering complex sites 
>>> for newer
>>> browser features.
>> I don't fully understand this. Can you give more concrete examples?

A couple of comments on these use-cases:

> - MathJax (http://mathjax.org) is a JS lib that facilitates putting 
> math onto the web by converting LaTeX or MathML markup in a page to 
> HTML. By default MathJax triggers off the onload event to run this 
> conversion on the page. When content containing math is dynamically 
> added to the page, MathJax must be called manually to convert the new 
> content. A DOM insertion listener could potentially be used to handle 
> this conversion automatically.
> - A similar use-case is element augmentation too complex for CSS 
> :before and :after

The previous cases respond to content being inserted into the page by 
(potentially) adding more content. Ideally these additional insertions 
wouldn't trigger additionally mutation listeners. I guess the current 
event system facilitates this with stopPropagation().

> - ARIA support in JS libs currently involves updating aria-attributes 
> to be appropriate to behavior the lib is implementing. Attribute 
> mutation listeners would allow an inverse approach - behaviors being 
> triggered off changes to aria-attributes.

As has been mentioned, listening for attribute mutations is horrendously 
inefficient because your handler has to receive every mutation, even if 
only interested in one attribute.

> - DOM insertion and removal listeners could facilitate the 
> implementation of automatically updating Table-of-* (Headings / Images 
> / etc).
Received on Friday, 8 July 2011 13:55:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC