- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sun, 03 Jul 2011 00:53:14 +0300
- 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 UTC