- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Tue, 29 May 2012 23:49:01 -0700
- 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 UTC