W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Feedback requested for UndoManager and DOM Transaction

From: Aryeh Gregor <ayg@aryeh.name>
Date: Thu, 27 Sep 2012 12:23:54 +0200
Message-ID: <CAKA+AxmBiU1BnrKepKrzT=p8A=4JaS+G_x-gJs=ttzhKEavfbQ@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: public-webapps <public-webapps@w3.org>
Belatedly: for the record, I'm fine with that.  I've appointed Ryosuke
a co-chair of the HTML Editing APIs Community Group.

On Wed, Mar 28, 2012 at 7:01 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> 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 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.
Received on Thursday, 27 September 2012 10:24:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC