- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jul 2011 15:28:35 -0700
- To: John J Barton <johnjbarton@johnjbarton.com>
- Cc: Olli@pettay.fi, Rafael Weinstein <rafaelw@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton <johnjbarton@johnjbarton.com> wrote: > Jonas Sicking wrote: >> >> We are definitely >> short on use cases for mutation events in general which is a problem. >> > > 1. Graphical breakpoints. The user marks some DOM element or attribute to > trigger break. The debugger inserts mutation listeners to watch for the > event that causes that element/attribute to be created/modified. Then the > debugger re-executes some code sequence and halts when the appropriate > listener is entered. Placing the listeners high in the tree and analyzing > all of the events is easier than trying to precisely add a listener since > the tree will be modified during re-execution. Debuggers can use internal APIs and doesn't need to be limited to using APIs exposed to web pages. In fact, in this case you probably want to use an internal API anyway as to ensure that the debugger steps in before any other of the mutation listeners have executed. In gecko you can for example use the nsIMutationObserver notification to implement this. > 2. Graphical tracing. Recording all or part of the DOM creation. For > visualization or analysis tools. See for example Firebug's HTML panel with > options Highlight Changes, Expand Changes, or Scroll Changes into View. See above. > 3. Client side dynamic translation. Intercept mutations and replace or > extend them. This could be for user tools like scriptish or stylish, dev > tools to inject marks or code, or for re-engineering complex sites for newer > browser features. I don't fully understand this. Can you give more concrete examples? / Jonas
Received on Thursday, 7 July 2011 22:29:32 UTC