[whatwg] Fixing undo on the Web - UndoManager and Transaction
ericu at google.com
Tue Aug 2 13:51:39 PDT 2011
"I'm somewhat skeptical of value of a manual transaction at this
point. If undo and redo had to be manually managed by a website, why
do we need to provide an API to manage them anyway? I guess it's a way
to enable undo/redo in Edit menu and provide Transaction's label as a
part of browser's native UI?"
I think the manual transaction is what I'd want to make undo/redo in
the edit menu work with jV
[https://addons.mozilla.org/en-US/firefox/addon/jv/]*. It does all
its edits by setting the contents of textareas, and has a very
different undo/redo granularity than the browser expects. If you
invoke the browser's undo/redo, jV's private undo stack gets out of
sync, and a jV undo after that will just corrupt the textarea's
It looks like using manual transactions would be the straightforward
way to make this work...I assume it could also be made to work with
managed transactions, but I'm having trouble picturing how that would
look from this early spec. Perhaps you could add a little sample code
of an app making a number of small changes and merging them into a
single undo record after each?
[*] Yes, it's out of date. It just needs a version-number-accepted
tweak--I'll get to that.
On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Hi all,
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with *new API for undo and redo*.
> Why? Because* undo and redo are broken on the Web today*. Whenever Web apps
> try to add a custom editing operation without using execCommand or do a "fix
> up" after browser executes a user editing action, user agents get confused
> by DOM mutations made by the apps and won't be able to undo or redo user
> editing actions and execCommand. This forces Web apps to re-implement undo
> and redo themselves, and in fact, *many rich text editors store innerHTML of
> a contenteditable element* as a string in their internal undo transaction
> history (a.k.a undo stack).
> Also, there's no way for Web apps to add new undo item and populate undo and
> redo menus on user agent's native UI. In addition, if an editor app has a
> widget with input/textarea, then the undo stack of the editor gets confused
> when the widget goes away because the undo transaction history exists only
> per document.
> In order to solve above and numerous other problems, we've come to a
> conclusion that we need to *add UndoManager and Transaction*.
> *UndoManager* is an interface for managing undo transaction history. It
> exists on a document and an element with the *undoscope* content attribute.
> UndoManager applies new transaction (i.e. make undoable DOM changes) and
> manage them. The main purpose of UndoManager is to communicate the list of
> undoable items with the user agent so that the user agent can provide a
> native UI (e.g. populating menu items with them).
> A *transaction* is a collection of DOM mutations that can be applied,
> unapplied, or reapplied. UndoManager manages transactions and execute
> unapply and reapply upon undo and redo respectively.
> There are two types of DOM transactions:
> - *Managed transaction* - the app supplies apply() and the user agent
> automatically takes care of undo and redo. It is *compatible with user
> editing actions and editing commands*, and allows Web apps to easily add
> new editing operations or fix up DOM after user editing actions or editing
> commands and still have the user agent manage the undo and redo.
> - *Manual transaction* - the app supplies apply(), unapply(), and
> reapply() and *the app takes the full control of undo and redo*. However,
> it is NOT compatible with user editing actions, editing commands, or managed
> transactions, meaning that, the user agents won't be able to undo or redo
> them. This transaction is useful for apps such as a collaborative editor
> that implements domain-specific undo or redo.
> You can see more concrete definitions of UndoManager and Transaction at:
> https://rniwa.com/editing/undomanager.html and see a list of uses cases at
> https://rniwa.com/editing/undomanager-usecases.html. The documents are
> incomplete and I need your feedback in order to refine details.
> Best regards,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
More information about the whatwg