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
