- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 12 Apr 2012 19:19:37 +0300
Few random comments about rniwa's UndoManager http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html "Also, any Web app that tries to mix contenteditable region or text fields with canvas or other non-text editable regions will have to reimplement undo and redo of contenteditable regions as well because the user agent typically has one undo transaction history per document" - that "typically" isn't true, and I think we should have multiple transaction histories, like some browser engines have, and like other programs tend to have. Should it be defined that <input> and <textarea> have implicit undoscope by default? What does "destroy the corresponding UndoManager for the scope." mean? If JS keeps a pointer to the manager, the object sure stays alive, and if I read the draft correctly, one can use some of the methods of a destroyed UndoManager. Why setting contenteditable clears transaction histories of descendants? This makes the API a bit harder to understand, but perhaps there is some reason... Link "DOM transaction group" doesn't point to anywhere. And "DOM transaction group" isn't really defined. If we need really merge option, would it make sense to have undoManager.transact(transaction); and undoManager.mergeTransact(transaction); DOMTransactionEvent doesn't seem to have proper dictionary to initialize it. Why the name DOMTransactionEvent, why not just TransactionEvent? So the idea is that when contenteditable area is modified by user input, UA automatically puts something to the transaction history? -Olli
Received on Thursday, 12 April 2012 09:19:37 UTC