- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jul 2011 12:18:31 -0700
- To: Olli@pettay.fi
- Cc: 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>
Hi All, I've finally caught up on all the emails in this thread. Here are my impressions so far. I don't think John J Barton's proposal to fire "before mutation notifications" is doable. Trying to make all APIs that would, or could, mutate the DOM throw or otherwise fail would be much too complex to implement and too surprising use. The list of APIs that we'd have to black-list would be far too long and would be heavily dependent on implementation strategies. We could take the approach workers take and make such scripts execute in a wholly different context where the harmful APIs simply aren't accessible. However such a context would, like workers, not have access to any of the normal functions or variables that the page normally uses. So I don't really see what you would do in such a context? I.e. what use cases would be solved if all you can do is run calculations, but not otherwise synchronously communicate with the outside world. And how would you tell such a notification which nodes are being modified since you can't pass references to the nodes as Nodes are one of the APIs that we don't want to expose. Additionally, how would you even register the callback that should be called when the notification fires? Note that workers always load a wholly new javascript file, there is no way to pass function references to it. 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. 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. I'll write up a proposal based on this idea. Others should feel free to beat me to it :) I'm less convinced of the part of Rafael's proposal that changes *when* notifications are called. If I understand the proposal, the idea is to not fire any notifications directly when the mutation happens, but instead all notifications are as soon as control is returned to the event loop. I.e. it's basically fully asynchronous, except that instead of adding a task to the end of the event queue, one is added to the beginning of it. Rafael, please do correct me if I'm wrong on the above. 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. 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. Finally, I actually do think it would be possible to create an API which allow pages to batch notifications. Something like this should work: document.notificationBatch(function() { element1.appendChild(someNode); element2.setAttribute("foo", "bar"); }); This would batch all notifications while inside the batch. However, I'm not convinced we should add such an API, at least in version one. And definitely not until there are proper use cases. Mutation events sort have have the ability to batch notifications by calling stopImmediatePropagation on events when they are fired and then manually firing events once the batch is done. Is this something people have done? Can anyone point to examples? Additionally, we'd have to decide what to do if someone spins the event loop inside a batch, for example by calling alert() or use synchronous XHR. / Jonas
Received on Thursday, 7 July 2011 19:19:37 UTC