On 08/11/2011 06:13 PM, Rafael Weinstein wrote:
Con:
Since the approach is bound to tasks, it is not clear what should happen
if event loop spins while handling the task. What if some other task
modifies the DOM[1], when should the mutation callbacks fire?
Because of this issue, tasks, which may spin event loop, should not
also modify DOM since that may cause some unexpected result.
I think the *pro* side of this you listed is more fair. Both Options 2
& 3 must answer this question. It's true that because Option 3 is
later, it sort of has this issue "more".
And it has a lot "more". Since for example when handling an event, all
the listeners for it are called in the same task and if one event
listener modifies DOM and some other spins event loop, it is hard to
see what is causing the somewhat unexpected behavior.
However, "what should happen" has been defined. In both cases, if
there are any mutations which are queued for delivery when an inner
event loop spins up, they are *not* delivered inside the inner event
loop. In both Options, they are always delivered in the loop which
queued them.
But what happens when event loop spins within a task, and some
"inner" task causes new mutations?
We want to notify about mutations in the order they have happened, right?
So if there are pending mutations to notify, the inner task must just
queue notifications to the queue of the outermost task.
This could effectively disable all the mutation callbacks for example
when a modal dialog (showModalDialog) is open.
Option 2 has similar problem, but *only* while handling mutation
callbacks, not during the whole task.
-Olli
Callback handling is moved far away from the actual mutation.
Pro:
Can batch more, since the callbacks are called later than in
option 2.
-Olli
[1] showModalDialog("javascript:opener.document.body.textContent = '';", "",
"");
