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

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

From: Alex Vincent <ajvincent@gmail.com>
Date: Thu, 1 Sep 2011 06:26:22 -0700
Message-ID: <CAEZ8443ig2gkaK1k2rZsz9QHYrKMixsSggzhVH7wZ7xobo+KQQ@mail.gmail.com>
There's too much good stuff going on, both in the specs, and in my own
project.  :-)  I noticed Ehsan's blog post about editing on the Web,
http://ehsanakhgari.org/blog/2011-08-31/future-editing-web .  I'm groaning
because I haven't been involved! :-p

A few thoughts on my mind:

   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.
   2. I think I'm not going to fully understand this spec until I at least
   try my hand at a test suite implementation, in Jasmine.  :-)
   3. I just spotted a flaw in our API's.  Imagine the following:
      -

      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?
      - Perhaps for this reason, .item() should return a readonly
      Transaction[], representing the transaction group.
      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.
   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.)
   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'd like a paragraph on that, at least, even if
   it's just to say localizations are outside the scope of the spec, and that
   language changes while an UndoManager exists may not be supported.

Alex
Received on Thursday, 1 September 2011 06:26:22 UTC

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