- From: Mike Wilson <mikewse@hotmail.com>
- Date: Sat, 6 Jun 2009 01:35:44 +0200
- To: "'Sergey Ilinsky'" <castonet@yahoo.co.uk>
- Cc: "'Webapps WG'" <public-webapps@w3.org>
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 UTC