Fwd: Use cases for Mutation Events

Hi, this is a collection of stuff from the webapps list...

------- Forwarded message -------
From: "Mike Wilson" <mikewse@hotmail.com>
To: "'Sergey Ilinsky'" <castonet@yahoo.co.uk>
Cc: "'Webapps WG'" <public-webapps@w3.org>
Subject: RE: [DOM3Events] Use cases for Mutation Events
Date: Sat, 06 Jun 2009 01:35:44 +0200

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.

===
>>> Sergey had written (at the start of the thread)
>>>> 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?
>>>
>> João replied
>>> Use cases:
>>>  - user triggered input, like when using contentEditable/designMode
> (Jonas intervened)
>> We should fix this by adding better events for user input into
>> contentEditable/designMode. Using mutation events for this is both
>> unnecessarily hard to use (I'd imagine), as well as unperformant (for
>> sure).

> I agree 100% that we need better events for user input in this regard,
> but we don't have them currently and Gecko and Webkit dispatch mutation
> events for user input on editable documents, and I know of a few high
> profile project that use them (although I can't disclose which).

>>>  - 3rd party libraries which want to know if the document mutates out  
>>> of
>>> their context
>>>  - 3rd party scripts (like ad scripts, or link to social networking or
>>> sharing sites) that change the document and the document wants to keep  
>>> some
>>> sanity in it
on which he expanded:

Whether there are libraries that use them or not, I honestly can't tell.
However there are scenarios where 3rd party libraries like jQuery or
prototype might require to know if the document has mutated to update
their internal data structures.
For the 3rd party scripts, it's quite common for sites to deploy 3rd
party scripts that embed links to social networking sites, bookmarking
services, embedding ads, embedding videos, etc. If somehow the script
breaks the main page's tree, a mutation event could help, although in
these cases, probably the load events would be good enough.

=====
and in reply to
> On Jun 4, 2009, at 12:17 , Jonas Sicking wrote:
> I generally agree, and I think that had mutation events never been
> implemented (I'm looking at you Hyatt) the world would probably not
> have missed them very much.

Robin Berjon replied...

More to the point, if browsers would give us XBL2 mutation events would be  
a whole lot less needed. (Yes Jonas, you know at whom I'm looking).

One thing that mutation events were used a lot for back in the old days of  
ASV (that supported them early on, IIRC in v3) was to add behaviour  
through decoration. Basically you could add a foo:draggable="true" on an  
element and know that a JS library would detect that change and make your  
element draggable. It's the poor man's XBL really.

=====

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/



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Sunday, 7 June 2009 16:11:55 UTC