- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Fri, 08 Jul 2011 00:43:46 +0300
- To: Webapps WG <public-webapps@w3.org>
- CC: Jonas Sicking <jonas@sicking.cc>, Rafael Weinstein <rafaelw@google.com>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Anne van Kesteren <annevk@opera.com>
On 07/08/2011 12:29 AM, Olli Pettay wrote: > On 07/07/2011 10:18 PM, Jonas Sicking wrote: >> 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 agree that having list of mutations is a good thing. > >> >> 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. > > And I also agree with this. > > I don't quite see the reason to postpone notification to happen > basically after all the other code in JS stack has run. Especially since the asynchronous-like approach behaves strangely when "spin the event loop" is needed. > Having a queue of notifications which are handled after outermost > mutation should be quite easy to understand. Also, that way converting > code from mutation events to mutation listeners should be easier. > > >> >> 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 21:44:35 UTC