Re: Mutation events replacement

On Sun, Jul 3, 2011 at 10:04 AM, John J. Barton <johnjbarton@johnjbarton.com
> wrote:
>
> The only part that is async in the Mutation Event replacement is further
> DOM events.


No!  Consider execCommand.  To notify scripts of node removals, we have to
pre-compute all nodes that are to be removed and make *synchronous* callback
for each before removing the node.

I don't think we can address your use case here.  Scripts'
>> intercepting and preventing mutations browser is about to make or
>> mutating DOM in the way browser doesn't expect is exactly what we want
>> to avoid.
>>
> The stated properties (goals)  of the replacement are (rephased):
>  1. No script operation in the middle of mutation,
>  2. Callback in order of mutation,
>  3. No propagation chain,
> Importantly the current proposal has an undesirable feature:
>  4. DOM modification in listeners is asynchronous.
> Preventing mutation in a 'before' listener still allows all of the
> properties as far as I know.


Sure if we can disallow all mutations including all properties of DOM nodes,
all properties of window, document, etc... and anything that implicitly adds
new properties or changes values of those properties or objects.

A "two-phase-commit" like solution can have all of these properties.  Copy
> Jonas' AttributeChanged algorithm from the page cited above. Replace "...ed"
> with "...ing". Add a flag 'cancelChange' initially false.  Add step
>    8b. If cancelChange is true, abort these steps and the DOM mutation.
>  Fire event DOMMutationCanceled
>

We don't want to make the event cancelable because canceling a mutation is
itself a mutation.  Consider the case of execCommand or user editing
actions.  As soon as we prevent one mutation, the rest of execCommand or
user editing actions fall into parts.

In fact we could go one step further and eliminate the undesirable feature
> #4: if notifyingCallbacks is true, all DOM write operations fail.  That way
> developers are never surprised by DOM functions that fail as in the current
> version. Instead developers will explicitly have to cascade modifications
> via separate events. This would be a much less mysterious solution.  In some
> places Firefox already works in the mystery way and speaking from experience
> it is not fun to figure out why your function calls have no effect.
>
> If you have both a before and and after event and both events prevent DOM
> write, then the programming paradigm could be clear:
>   before handlers cancel mutations and signal 'after' handlers to stage
> alternatives
>   after handlers stage responses to mutation or alternatives to canceled
> mutations.


This feature requires enormous amount of work in the user agent side.  We
need to see more use cases outside of extensions and variants.

At this point, I'm still strongly against implementing such an API as an
user agent implementor.

- Ryosuke