Re: Mutation events replacement

On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
<johnjbarton@johnjbarton.com> wrote:
> 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?

I don't think we can support this use case in general.  We're trying
to avoid invoking scripts synchronously and your use case requires
exactly that.

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

Why do you need to get notified before the mutation?  Again, this is
exactly the sort of usage that causes us headaches and what we want to
avoid because scripts can then modify DOM before we make mutations.

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

I don't think we can address your use case here.  Scripts'
intercepting and preventing mutations browser is about to make or
mutating DOM in the way browser doesn't expect is exactly what we want
to avoid.

- Ryosuke

Received on Saturday, 2 July 2011 19:37:44 UTC