|Immediately||After modifications||End of current task||New task|
|Con||Because mutations must be delivered for some DOM operations before the operation is complete, UAs must tolerate all ways in which script may invalidate their assumptions before they do further work.||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, 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.
Callback handling is moved far away from the actual mutation.
|It's too late. Most use cases for mutation observation require that observers run before a paint occurs. E.g. a widget library which
watches for special attributes. Script may create a |
and an observer will react to this by decorating the div as a FooButton. It is unacceptable (creates visual artifacts/flickering) to have the div be painted before the widget library has decorated it as a FooButton.
Both of these options appear to be non-starters. Option 1 has been shown by experience to be an unreasonable implementation burden for UAs. Option 4 clearly doesn't handle properly important use cases.