- From: Rafael Weinstein <rafaelw@google.com>
- Date: Thu, 7 Jul 2011 14:32:29 -0700
- To: Ryosuke Niwa <rniwa@webkit.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Olli@pettay.fi, 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 1:58 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: > On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking <jonas@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. Right. Olli & Jonas, I'd really like to understand your thinking about this. Are we not understanding something about your proposal? If accommodating the above is a goal, it seems like the only option is to have mutation events be fully synchronous. I.e. It doesn't seem acceptable to encourage a widget author to expose an API that depends on never being called inside a mutation callback and/or prevents it from being used as a building block for a higher-level abstraction. > > Agreed. We probably need more real-world use cases. > - Ryosuke >
Received on Thursday, 7 July 2011 21:32:53 UTC