[whatwg] Feedback on UndoManager spec

On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor <ayg at aryeh.name> wrote:

> On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > I don't want string because then I'd have to do:
> > if (mode == 'reapply')
> > instead of
> > if (isReapply)
> > and the former is much more verbose.
>
> It's a few extra characters.  I really think the increase in clarity
> is worth it.  Boolean parameters are much more confusing, and should
> be avoided wherever possible.
>

+1. I'm also OK with the argument if it's a string.


> > That won't work for a collaborative editor because undo/redo may need to
> > make DOM changes other than just restoring DOM states. For
> example, changes
> > made by other users can't be undone/redone by the local user, and those
> > changes may also have mutated the highest node affected by automatic
> > transactions. And authors still want to be able to sync the list of
> > undo/redo items with UAs (e.g. to enable "undo" item in "Edit" menu).
>
> Okay, good.  That's another use-case.  I think it would be helpful if
> you added these use-cases to the spec so that it's easier to see why
> it's designed the way it is.
>
> Now I suggest that automatic transactions behave as I described, also
> running reapply/unapply but undoing any DOM changes they do.  Thus for
> things like tracking canvas state, the author can still use them
> safely.  For collaborative editing, I suggest that we avoid the
> problems due to mixing manual and automatic transactions by making it
> per-UndoManager instead of per-transaction.  So instead of an
> isAutomatic property for transactions, have methods on UndoManager,
> maybe enableManualTransactions() and disableManualTransactions().
> Then when one of these is called, clear the transaction history.  That
> way, we don't have to worry about undefined behavior when manual and
> automatic transactions are mixed, and we still satisfy all use-cases.
> Collaborative editors won't want to use automatic transactions, right?
>

Another use-case: a (possibly collaborative) slide editor (e.g. Google
Presentations). Imagine that each text box in a slide is a contentEditable.
You want adding/removing textboxes and/or slides to be manual transactions,
but actual text editing in the text boxes to be automatic. And you want all
this in the same undo stack.

Received on Friday, 28 October 2011 11:47:04 UTC