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

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Sun, 03 Jul 2011 00:53:14 +0300
Message-ID: <4E0F934A.4000301@helsinki.fi>
To: johnjbarton@johnjbarton.com
CC: public-webapps@w3.org
On 07/02/2011 08:46 PM, John J. Barton wrote:
>
>>Olli Pettay
>>Tue, 28 Jun 2011 04:32:14 -0700
>>These are *not* DOM-Event listeners. No DOM Events are created, there
>>are no capture phases or bubbling phases. Instead you register a
>>listener on the node you are interested in being notified about, and
>>will get a call after a mutation takes place.
>
> The proposed model will be great for "element observation", but, as far
> as I understand it, "document observation" and especially
> "document transformation" would not be supported.
>
> Perhaps someone can outline how the replacement would solve two
> use cases for DOM mutations:
>
> 1) break on mutation. In Firebug we add DOM mutation listeners to
> implement graphical breakpoints. The replacement would work fine for
> local, element observation breakpoints like add/remove attribute.
> If my goal is to break on addition of elements with class="foo", then
> I guess I have to listen for addChildlistChanged on all elements, and
> add an additional addChildlistChanged listener for each new element?
> So in general one would implement document observation by walking
> the DOM and covering it with listeners?
>
> 2) element transformation. The replacement fires "after" a mutation.
So do current mutation events, except 
DOMNodeRemoved/DOMNodeRemovedFromDocument

-Olli



> Library or tools that want to transform the application dynamically want
> to get notification "before" the mutation. A common solution then is
> to bracket changes:
> "beforeChange" or "onModelChanging"
> "afterChange" or "onModelChanged"
> Of course element transformation may want to prevent the current
> change and replace it. Some changes are reversible so the observed
> change can be countered with a remove (at unknown cost to performance
> and user experience). But some changes are irreversible such as
> script tag addition. So, for example, I can't see how to implement
> JS pre-processing using only the after event. (This may not be
> possible with the current mutation events either, but it is something
> I want to to).
>
> Thanks,
> jjb
>
>
Received on Saturday, 2 July 2011 21:53:53 GMT

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