Re: Mutation events replacement

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