- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 27 Sep 2012 12:23:54 +0200
- 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