Re: Mutation events replacement

On Mon, Jul 4, 2011 at 11:01 AM, Dave Raggett <dsr@w3.org> wrote:
>
> How exactly would the listener know the previous state?
>
> For a concurrent editing app, it is important to be able to describe
> changes reversibly so that you can revert the DOM when a given local edit
> isn't accepted, or you need to revert before applying accepted changes from
> other clients. I have been able to get this to work fine with the existing
> mutation events. Of course, I avoid changing the DOM within a mutation event
> listener, but it is easy to defer such changes by a call to setTimeout, e.g.
> with a time of zero. I would be quite happy for the browser to throw an
> exception when a mutation event listener tries to call an unsafe API, as
> this way developers would rapidly learn of their mistake and switch to
> better practices.


If we wanted, we can have a flag that adds new properties that contain old
values, nodes, etc...  And if we have a list of all mutations that happened
in the order, then you should be able to unapply/reapply the DOM mutations
as needed.

On Mon, Jul 4, 2011 at 11:14 AM, John J. Barton <johnjbarton@johnjbarton.com
> wrote:
>
> Sorry, it was actually in Jonas' post you quoted:
>
>
> >The only undesirable feature is that code that mutates the DOM from
> >inside a callback, say by calling setAttribute, can't rely on that by
> >the time that setAttribute returns, all callbacks have been notified.
> >This is unfortunately required if we want the second desirable
> >property listed above.
>
>
> If I understand correctly, this description understates the problem.
> Isn't it the case that all DOM mutations will act differently in mutation
> listeners?  Code tested outside of mutation listeners can fail inside of
> mutation listeners, correct?
>

Only if the code expects mutation events be fired synchronously (e.g. the
code relies on some mutation event listeners modify DOM synchronously as it
mutates DOM).  However, all DOM mutations made in mutation listeners will
take effect immediately in Jonas' proposal.

This is indeed an undesirable feature and I don't believe it is necessary.
> We can achieve the second desirable property, which is really about avoiding
> mutation in mutation listeners, in other ways. Instead of special case
> asynchrony, make it explicit asynchrony.  Developers will hate it, just like
> they hate XHR asynchrony, but it's better than unreliable programs.
>

I agree that mutation observers are called sometimes synchronously and
sometimes asynchronously is confusing.


>
>  The
>
> list of functions is not specified directly, but is implicit in the
> algorithm: some function's actions become asynchronous.
>
> No. Change notifications are queued, and the listeners handling the
> queue will called at the time when the outermost DOM mutation is about
> to return.
>
> How can I reconcile your answer with the idea that setAttribute() does not
> work synchronously in my mutation listener? Can my mutation listener mutate
> the DOM and expect those mutations to act the way they do outside of the
> listeners?  My understanding is no: the API works differently inside of
> mutation listeners.
>

It works synchronously.  It just fires mutation events as the result
of setAttribute will fire asynchronously.

- Ryosuke