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
