On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <jo...@sicking.cc> wrote: > > I don't think John J Barton's proposal to fire "before mutation > notifications" is doable.
I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another synchronous event here. In short before spending more time on this, I'd like to see a > comprehensive proposal, including a description of the use cases it > solves and how it solves them. I strongly doubt that this approach is > practical. > Totally agreed. I really like Rafael's proposal to pass a list of mutations that has > happened to the notification callbacks. This has the advantage that > scripts get *all* the changes that has happened at once, making it > possible to make decisions based on all changes made, rather than > piece-wise getting the information in separate callbacks. It also has > the advantage that we can provide much more detailed information > without having to make multiple calls from C++ to JS which is good for > performance. For example it seems very doable to provide lists of all > nodes that has been removed and added while still keeping performance > reasonable. > Enthusiastically agreed. I'll write up a proposal based on this idea. Others should feel free > to beat me to it :) > Nice! Looking forward to it. The main concern that I have with this proposal is that it's so > different from mutation events that it might not satisfy the same use > cases. Consider a widget implementation that currently observes the > DOM using mutation events and makes it possible to write code like: > > myWidgetBackedElement.appendChild(someNode); > myWidgetBackedElement.someFunction(); > > where someFunction depends on state which is updated by the mutation > event handler. Such a widget implementation is simply not doable with > these semi-asynchronous callbacks. > Right. But on the other hand, if this code were to run inside a mutation observer, it won't work in your proposal either. So the questions is whether writing a function that depends on state updated by the mutation observer without a mutation observer, and then later calling it inside a mutation observer happens frequently enough to annoy developers or not. On the other hand, maybe this isn't a big deal. We are definitely > short on use cases for mutation events in general which is a problem. > Agreed. We probably need more real-world use cases. - Ryosuke
