[whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

On Thu, Sep 1, 2011 at 6:26 AM, Alex Vincent <ajvincent at gmail.com> wrote:
>
>   1. I think we should start writing a test suite, for two reasons.  First,
>   to get some idea how this works in practice, with a reference
> implementation
>   in JavaScript.  That will help us iron out some of the API debates we've
>   been having (reapply, specifically).  Second, a test suite can help all
> the
>   implementers implement the same thing.
>

Implementing it in JavaScript will be somewhat challenging because
managed/automatic transactions need to keep track of all changes made by a
function it's calling.  It'll require a heavy use of mutation events (and
they're going away!)

     myEditor.undoManager.transact({apply: function () {
> insert(document.createTextNode('o')) }, label: 'First transaction'});
>      myEditor.undoManager.transact({apply: function () {
> insert(document.createTextNode('k')) }, label: 'Merging transaction'},
> true);
>
>      - User calls myEditor.undoManager.item(0).label.  Which label does he
>      get back?  For that matter, which transaction does he get back, and
> which
>      transaction is forever hidden from him?
>

You get an array (should make it immutable) that contains both transactions.
So you get undefined.  But this behavior is stated in my working draft:
http://rniwa.com/editing/undomanager.html#transaction-group

I agree I need to refine the definition of item.

     4. Did we talk about a maxlength for the UndoManager?  If we allow an
>   infinite number of transactions in an UndoManager, a lot of memory could
> get
>   eaten up.  I'd say the page author should be able to limit the number of
>   transactions kept in memory at his or her discretion.
>

I was thinking that we should just put a fixed limit on how many
transactions can be stored, and give no guarantee beyond that point.  I
don't think authors should be able to control that limit because that'll
hinder user agent's ability to do so.

  5. Section 2.1 is Definitions, but several of the definitions are
>   scattered around the specification (Transaction, for example), and do not
>   start with basic definitions.  I think this section needs to be
> rewritten,
>   starting with the most basic definitions.  (Define a transaction. Define
> a
>   transaction group based on the definition of a transaction.  Define an
> undo
>   stack based on the definitions of a transaction group and a transaction,
> and
>   so on.)
>

That might be a good idea.  Will try.

  6. I'm wondering a bit about localization of the Transaction object's
>   label.  It's probably an unnecessary concern (this specification
> shouldn't
>   go too deep), but I'm just wondering how both scripted and native
>   transactions will detect the language of the webpage and generate
>   locale-specific labels.


I think that's fine.  As far as I know, there are no major user agents that
let can change the current locate in the middle of a session.  And labels
should be localized to user agent's locate since it'll be shown as a part of
its native UI.

- Ryosuke