[whatwg] Feedback on UndoManager spec

[Ojan Vafai]

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.