W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] UndoManager questions

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Tue, 29 May 2012 23:49:01 -0700
Message-ID: <CABNRm63KZnBpRpAW20eztwR_SO-d2ztQCXfDn4oS11Q-QU8PEQ@mail.gmail.com>
To: Alex Vincent <ajvincent@gmail.com>
Cc: whatwg@whatwg.org, Jonas Sicking <jonas@sicking.cc>, Ehsan Akhgari <ehsan@mozilla.com>
Done: http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html

- Ryosuke

On Tue, May 29, 2012 at 9:17 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Sat, May 26, 2012 at 8:01 PM, Alex Vincent <ajvincent@gmail.com> wrote:
>
>> For those not familiar, the spec lives here:
>> http://rniwa.com/editing/undomanager.html
>
>
> It has been moved to
> http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html
>
>
>> * The spec is inconsistent in a few places.  For instance, in the green
>> non-normative section, clearUndo states:
>> Removes entries in the undo transaction
>> history<
>> http://rniwa.com/editing/undomanager.html#undo-transaction-history>before
>> position<
>> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>and
>> resets
>> position<
>> http://rniwa.com/editing/undomanager.html#dom-undomanager-position>to
>> 0.
>>
>
> This statement in the non-formative section is correct.
>
> However, in the normative part, it states:
>> The clearUndo() method must remove all entries in the undo transaction
>> history <
>> http://rniwa.com/editing/undomanager.html#undo-transaction-history>after
>> the undo
>> position <http://rniwa.com/editing/undomanager.html#undo-position>.
>>
>
> This statement is incorrect. Will fix.
>
> * The spec mentions a "DOM transaction
>> group<http://rniwa.com/editing/undomanager.html#dom-transaction-group>",
>> but does not define that.
>>
>
> Will fix.
>
> * When adding a transaction to a DOMTransaction[] as part of execute's
>> merge being true, do we add it to the beginning or the end of the
>> list? This matters for .item().
>
>
> I meant at the end, but now that I realize this is inconsistent with the
> way entries in the undoManager is ordered. Will change so that it'll be
> added at the beginning instead.
>
> * Exception handling is woefully undefined in this spec:
>> ** If my transaction throws an exception during UndoManager.execute(), how
>> should that be handled? What happens to transaction groups that were
>> previously undone?
>> ** If my transaction throws an exception during .undo(), how should that
>> be
>> handled?
>> ** Ditto redo.
>>
>
> Let's start a new thread about this.
>
> * What precisely lives at UndoManager.item(0)?  The most recently completed
>> transaction, or the oldest?
>>
>
> The most recent.
>
> * When UndoManager.execute() is called with an object not implementing
>> .undo, or .redo, should we fire some kind of warning to the user?  What
>> should happen when we try to undo that transaction?
>>
>
> There are valid use cases for creating transactions without undo or redo
> method (e.g. need to do something only in undo such as updating toolbar).
>
> - Ryosuke
>
Received on Wednesday, 30 May 2012 06:50:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT