[whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

On Tue, Aug 2, 2011 at 11:30 AM, Ehsan Akhgari <ehsan at mozilla.com> wrote:

> This is a very nice proposal; thanks for working on this, Ryosuke!  I have
> a number of questions and concerns on it, and I would appreciate if you can
> comment on these:
>

Nope!  I just REALLY want to fix this.

1. The definition of @undoscope seems to not address the question of whether
> the document element should be an Undo Scope or not.
>

Each document has its own undo scope:
http://rniwa.com/editing/undomanager.html#undo-scope

2. @undoscope seems to make it very hard to support the usecase of moving
> the undo scope from an element to another.  (I'm not sure if that is a
> concern that we need to address at all, though).
>

Right, I don't support that use case.  But I couldn't think of a case where
this is useful.  Also, I was concerned that this will make browser's undo
management much harder since I don't know how Opera and IE manage undo
transaction history.

3. In regard to "Should apply return a boolean value indicating whether it
> successfully applied or not?", answering yes means that we should make sure
> that we're going to be able to cleanly revert a transaction when it fails,
> right?  Also, saying yes here means that we should decide what happens if
> that transaction is in a transaction group.  ... all of which makes me want
> to say no.  :-)
>

Not necessary.  I think saying "yes" means that apply function returned
"true", and we've successfully added new entry to the undoManager. i.e.
apply nor DOM mutation handlers did something insane like removing
undoManager or interfering with DOM mutation, etc...  Also, if we add
editAction/transaction event, we may want to make it cancelable so that the
entire transaction may be prevented (not individual mutations).

So returning boolean will let websites figure out whether a transaction was
really added to the list or not.

4. In regard to "Need to restore selection as well", is that something which
> we want all the time?  Imagine an "indent" transaction which indents a
> paragraph by increasing its start margin, should it change the selection
> when it's undone?
>

Oh, so what I mean is that selection needs to be restored to the state
before the transaction was applied.  e.g. when I select then delete "hello
world" and undo, I should be selecting "hello world".

5. I have serious doubts about the current specification of manual
> transactions.  I don't know why we need to exclude them from group
> transactions, but honestly, I'm not sure why we need to have them at all.
>  What use cases are we trying to address by manual transactions that would
> otherwise be impossible to address with managed transactions?
>

In collaborative editing apps, it's infeasible for the UA to manage undo
transaction history because their undo history will be a tree, or an
arbitrary graph.  Also if you wanted to make an app that modifies both
contenteditable region and canvas, you'll almost certainly need to modify
canvas by script manually and yet you may want to let UA manage the undo
transaction history of text fields.

And the reason scripts want to use manual transaction as supposed to just
modifying document, is to update UA's native UI.  Without manual transaction
or a comparable mechanism, UA won't be able to enable undo/redo menu items
or show a list of undoable items in their menu.

6. I think if we want to address selection saving/restoring, that part
> belongs to the "Mutation of DOM" section.  We might also need to address
> some other editing related stuff in the DOM state, such as the keyboard
> layout language, selection, etc.
>

That's a good point.  I'd have to look into what each UA does and what needs
to be preserved.  Aryeh, do you have any idea as to what UAs do for native
editing actions?

 7. I'm not sure if we should leave the interaction of @contenteditable and
> @undoscope unaddressed.  At the very least, we need to specify whether by
> default all contenteditable elements on a web page share the same undo
> manager or not.  If I were to pick the default, I would suggest that by
> default they should all share the document's undo manager.
>

Yes, they do share the document's undo manger.  I'll make sure to explicitly
say that in the document.

8. As a last comment, I think a better name for UndoManager is
> TransactionManager, since, well, that's what it really is!  :-)


Alternatively, we can change the name "transaction" to something else
because "transaction" sounds too general.

- Ryosuke