- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Fri, 08 Jul 2011 00:29:03 +0300
- To: Jonas Sicking <jonas@sicking.cc>
- 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>
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. 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:30:09 UTC