A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

UndoManager Problem Descriptions

From WHATWG Wiki
Revision as of 19:21, 7 November 2011 by Aryeh Gregor (talk | contribs) (Create page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Use-cases from rniwa's page and a whatwg thread, patterned after Microdata Problem Descriptions.

General principles:

  • Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
  • Don't allow any functionality that

Managing DOM changes


  • A site wants to allow adding a special type of site-specific markup, say <span class=foo>.
  • A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. All changes are either in the DOM, or could be stored in the DOM (using data-* or such).
  • A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
  • A code editor that implements auto-completion should be able to use user agent's undo transaction history.


  • It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
  • The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
  • The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
  • Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

Separate undo histories


  • A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.


  • The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

Non-DOM state


  • A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.


  • It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
  • It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
  • DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

Custom control of DOM state


  • Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
  • Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.


  • The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
  • If browsers try to merge changes themselves, the algorithm must be well-defined. 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.
  • It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
  • Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.