W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2011

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

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Thu, 1 Sep 2011 11:36:21 -0700
Message-ID: <CABNRm613R=mhm36z81BTEMCLBv4zGCZe_wj5qWoOYszPuSVEDg@mail.gmail.com>
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:

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
Received on Thursday, 1 September 2011 11:36:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:36 UTC