W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Fri, 08 Jul 2011 00:43:46 +0300
Message-ID: <4E162892.4010207@helsinki.fi>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC