UndoManager 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 isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

Managing DOM changes

Scenarios:

A site wants to allow adding a special type of site-specific markup, say <span class=foo>.
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.

Requirements:

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.

Scenarios:

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.

Requirements:

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

Scenarios:

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.

Requirements:

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.

Scenarios:

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.

Requirements:

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 should be well-defined if possible. 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. Issue: Is this doable? Refer to mailing list discussion.
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.

Scenarios:

A standard rich-text editor with various buttons and drop-downs. Undo/redo should not automatically affect any of the UI's state. E.g., if the user selects "red" in the color drop-down, undo should not change it back to the previous selection.
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. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

Requirements:

The browser must not touch the UI parts of the page, but still has to fully manage the non-UI parts.
Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the UI parts of the page, there is no reason for the UA to make any automatic DOM changes at all.