[whatwg] Feedback on UndoManager spec

On Fri, Oct 28, 2011 at 12:20 PM, Aryeh Gregor <ayg at aryeh.name> wrote:
>
>  > Another use-case: a (possibly collaborative) slide editor (e.g. Google
> > Presentations). Imagine that each text box in a slide is a
> contentEditable.
> > You want adding/removing textboxes and/or slides to be manual
> transactions,
> > but actual text editing in the text boxes to be automatic. And you want
> all
> > this in the same undo stack.
>
> Well, there are two possibilities:
>
> 1) When undoing the manual transactions, the author intends to get
> back to the exact same DOM as before.  In this case, it's no problem
> if the UA enforces this automatically: it's just doing what the author
> wanted.
>
> 2) When undoing the manual transactions, the author does not intend to
> get back to the exact same DOM as before, maybe because someone else
> has modified it.  In this case, automatic transactions are useless
> anyway.  The UA's best effort will not be what the author wants,
> particularly if it's undefined.  For instance, in a collaborative
> editor, if someone else has added some text that shouldn't be undone,
> the UA will fail randomly.  Thus the author cannot rely on automatic
> transactions and will have to do the merge resolution themselves.
>

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.

- Ryosuke

Received on Friday, 28 October 2011 12:54:03 UTC