Re: Feedback requested for UndoManager and DOM Transaction

Hi,

I've moved my draft to W3C repository at
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html

At this point, I'd like the editing community group to be in charge of this
proposal.

- Ryosuke

On Mon, Dec 5, 2011 at 11:44 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> Greetings all,
>
> As you maybe all aware, I've been working with developers of
> CKEditor, TinyMCE, and Google Docs along with developers from WebKit,
> Mozilla, and Opera on new UndoManager and DOM Transaction specification<http://rniwa.com/editing/undomanager.html> for
> the last several months. And it's about time I ask for feedback from
> broader audience!
>
> 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).
>
> There is also no way for Web apps to add new undo items 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 DOM Transaction*.
>
> *UndoManager* is an interface for managing *undo transaction history*.
>  It exists on a document and an element with the undoscope content
> attribute.
> 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 *DOM transaction* is a sequence of DOM mutations that can be
> applied, unapplied, or reapplied.  There are two types of DOM transactions:
>
>    - *Automatic DOM transaction* - Only the logic to make the initial DOM
>    changes is supplied by the author, and the user agent takes care of undo an
>    redo. It is *compatible with user editing actions and editing commands*,
>    and allows Web apps to easily do custom editing operations or fix up DOM
>    after user editing actions.
>    - *Manual DOM transaction* - Web apps specify logics to apply,
>    unapply, and reapply the transaction and *takes the full control of
>    undo and redo*.  This transaction is useful for apps such as
>    collaborative editor or canvas drawing apps that need to implement custom
>    logic for undo and 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 http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions.  I
> consider the current proposal to be ready for implementation feedback, and
> as such, I plan to prototype it in WebKit and give my own feedback as well.
>
> I sincerely request for your feedback on the proposal, and I will answer
> any question(s) you may have about the proposal.
>
> Best regards,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>
>