[whatwg] Feedback on UndoManager spec

On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor <ayg at aryeh.name> wrote:
>> It's a few extra characters. ?I really think the increase in clarity
>> is worth it. ?Boolean parameters are much more confusing, and should
>> be avoided wherever possible.
>
> +1. I'm also OK with the argument if it's a string.

Jonas?

> 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.

In other words, even in a collaborative editor, what would be a case
where automatic transactions would actually be useful?  They'll just
fail randomly with undefined behavior.  So suppose we have some
hypothetical collaborative editor.  What's an example sequence of
mixed automatic and manual transactions that would occur where the
automatic transactions will reliably work, but the manual transactions
can't also be automatic?

Received on Friday, 28 October 2011 12:20:37 UTC