W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

[whatwg] Feedback on UndoManager spec

From: Aryeh Gregor <ayg@aryeh.name>
Date: Mon, 7 Nov 2011 11:15:34 -0500
Message-ID: <CAKA+AxkFYW0bSW77Qd-43LW4tUOv3gqvcdhF+UpzDPGWEVHkjQ@mail.gmail.com>
(sorry for the long delay in responding, life is sometimes flaky for
me right now)

On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> But that manual transaction may be mutating DOM outside of the editable
> region. i.e. in the slide app case, you may have plane that's showing a list
> of slides. Since that's a part of the UI provided by the app, the DOM state
> of that UI may change over time without necessarily undoing or redoing
> insertions and removals of slides. So when you undo/redo an insertion of a
> slide, the exact change you make to the DOM may not be a mere
> restoration.?Yet, the app still may want undo/redo in text fields to be
> implemented by UAs.

What you're saying is that maybe there will be parts of the DOM that
the author doesn't want the UA to touch?  In that case, how about we
let the author specify that UA undo/redo shouldn't affect certain
subtrees?  E.g., have the plane that shows a list of slides in <div
noundo> or something like that.  Then just like the UA doesn't
undo/redo DOM changes outside the undo scope, it shouldn't undo/redo
changes in a noundo region (or whatever you want the attribute to be
called).

This way, again, the UA will never be faced with the problem of
undoing/redoing changes in a part of the DOM that the author may have
tampered with.  This is critical for making the APIs work reliably --
if automatic undo/redo can fail because of authoring bugs, authors
won't want to use it.  It also simplifies the API by getting rid of
the distinction between automatic and manual transactions.

Are you (or anyone) making a list of use-cases somewhere?  If not, I
guess I will, because it's really essential to designing a good API.
Received on Monday, 7 November 2011 08:15:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC