[whatwg] Feedback on UndoManager spec

On Mon, Nov 7, 2011 at 12:26 PM, Aryeh Gregor <ayg at aryeh.name> wrote:

> I based it off http://rniwa.com/editing/undomanager-usecases.html,
> plus posts in this thread.


Thanks!

* "The author must not be forced to deal with manually handling DOM
> state just because they want to handle non-DOM state."


I disagree with this requirement. This should be an opt-in feature, not
something forced upon authors.


> Currently, if I want the UA to automatically handle DOM state, I cannot
> provide
> unapply or reapply methods.  This means that if I need to handle
> non-DOM state, like for a canvas editor, then I have to keep track of
> all my DOM changes too.  I should be able to write a canvas editor and
> still let the UA handle all DOM state.  This would mean allowing
> unapply/reapply methods to be provided for automatic transactions,
> with the UA undoing any DOM changes they cause.
>

Calling unapply/reapply methods for automatic transaction seem like a good
non-controvertial change. Will make the change in the next iteration.

* "If browsers try to merge changes themselves, the algorithm should
> be well-defined if possible. Otherwise it will just confuse authors
> and not be useful, because it will succeed in some browsers and fail
> in others, or have unpredictable results."


I don't think this is possible for various implementation-specific reasons.

Okay, thanks.  This is the key point I was missing.  Just so I
> understand, what's supposed to happen here:
>
> 1. Some changes get made in an automatic transaction.
> 2. Some changes get made in no transaction at all, just a script
> calling DOM methods.
> 3. execCommand("undo")
>

It depends. If the DOM changes made in step 2 does not mutates the highest
node affecting the automatic transaction in step 1, then step 3 succeeds
and UA undoes every DOM change made in step 1.

If the DOM changes made in step 2 mutates the highest node affecting the
automatic transaction in step 1, then UAs still does its best to unapply
the transaction but doesn't need to guarantee the states are restored
completely.

Is the resulting DOM just undefined?  Why isn't it defined to be
> whatever the state was before the automatic transaction, so any
> intervening changes just get undone too?


As far as I understand, implementing such a behavior will be extremely
expensive in WebKit and I don't want to do that.

Is Gecko's behavior here bad?  What disadvantages does it have?  Can
> we work around those disadvantages while still meeting all use-cases,
> and keeping behavior performant *and* well-defined?


We can't. That's why I have spec'ed the way it is. Keeping the entire DOM
state is extremely expensive.

Yes, we'd have to be careful about what happens if the attribute is
> added/removed.  However, it should be possible to do that, and then
> behavior will be well-defined, which is a big plus.


Yeah, it'll be nice if we could define the behavior precisely but then
again, there's nothing that prevents authors from modifying DOM in any
arbitrary way.


> Obviously, as you point out, this attribute is only really useful if the
> UA tracks *all*
> DOM changes as part of the last transaction, as Gecko seems to do.
>

This is very expensive to implement, and I'll be opposed to implementing
such a behavior at least in WebKit.

- Ryosuke

Received on Monday, 7 November 2011 17:03:00 UTC