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. 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