Re: Mutation events replacement

>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