W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

RE: [DOM3Events] Use cases for Mutation Events

From: Mike Wilson <mikewse@hotmail.com>
Date: Sat, 6 Jun 2009 01:35:44 +0200
Message-ID: <BAY116-DAV34AE62805D3C873EB3791A4480@phx.gbl>
To: "'Sergey Ilinsky'" <castonet@yahoo.co.uk>
Cc: "'Webapps WG'" <public-webapps@w3.org>
Message-ID: <08ff01c9e636$58be2a90$0a01a8c0@mikedeskxp>
The below use-cases overlap with what other people have already 
mentioned but I reiterate them anyway as there might be some
slightly different twist to them:

Keeping updated statistics of page DOM
--------------------------------------
The most popular examples of these today are probably selector
engine libraries. They can benefit from scanning the DOM tree
once into a cache, and then let the cache be updated/invalidated
based on mutation events. Now hopefully querySelectorAll() 
support will void this particular usage, but there will always
be other uses needing to do similar things, be it keeping an 
updated count of text length or doing something selector based 
not supported by QSA, f ex reverse selector mapping.

Widgetify dynamically created markup
------------------------------------
Widgets may be used to override or decorate page markup 
cooperatively (the markup knows about it and uses special tagging
to trigger it) or silently (a page script looks for patterns in 
the markup to direct widget creation at).
Usually this is done as a page-wide search-and-replace at page 
load. 
Though, when markup is created dynamically throughout the page's
lifetime, f ex through click events that "expand a pane", it is
hard to do the silent/uncooperative replacement. Mutation events
let us solve this and trigger widget creation when any new 
matching markup appears.

Best regards
Mike Wilson

Sergey Ilinsky wrote:
> Hi,
> 
> For me it is not clear at all what are the use cases for DOM 
> Mutations Events on web pages (so maybe simply dropping their 
> implementation would be an option?).
> 
> If the group could first identify the use cases for Mutation 
> Events on the web pages, then:
> a) it would become clear to everyone whether the progress is needed
> b) creating proposals on progress would become easier, a 
> proposal would have to satisfy these use case to prove its viability
> 
> Other thoughts:
> 1) If I am the author to the scripts that modify document, 
> then I am indeed aware of what gets changed. If I am not the 
> author, I shall then not have been notified on the change. 
> The use cases such as "debugger" do not count here - it would 
> be possible to offer required APIs (such as DOM Mutation 
> Events) to them only, without needing the API to populate on 
> the page. And this is not a sucrifice to run page 50% slower 
> caused by the Mutation Events turned on on behalf of a 
> debugger, right?
> 
> 2) I can see Mutation Events as the extension point that 
> enables implementation of the technologies that are not 
> available in the browser. However this is not a "normal" 
> usecase that web browsers are here to face.
> 
> Sergey/
Received on Friday, 5 June 2009 23:37:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT