- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Sat, 2 Jul 2011 12:36:49 -0700
- To: johnjbarton@johnjbarton.com
- Cc: public-webapps@w3.org
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