- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Thu, 12 Apr 2012 10:27:01 -0700
On Thu, Apr 12, 2012 at 9:19 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote: > > Should it be defined that <input> and <textarea> have implicit undoscope > by default? The problem is that we don't have a way of removing undo scope. We might need to allow undoscope=false/true. > 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. > Yeah, I need to define it properly. It basically means that element's undoManager property will return null thereafter. I should define what happens when you call methods on those orphaned methods I guess. Why setting contenteditable clears transaction histories > of descendants? This makes the API a bit harder to understand, but > perhaps there is some reason... > Because it complicates the interaction with browser's native editing commands. Link "DOM transaction group" doesn't point to anywhere. > And "DOM transaction group" isn't really defined. > Oops, DOM transaction group should go away. It shouldn't exist. Will update. If we need really merge option, would it make sense to > have undoManager.transact(**transaction); and > undoManager.mergeTransact(**transaction); > I don't think we want to have two methods. DOMTransactionEvent doesn't seem to have proper dictionary to initialize it. > Oops, will fix. Why the name DOMTransactionEvent, why not just TransactionEvent? > We can change it if you really want. We didn't want to sound like it's related to IDB's transaction or any other concept named "transaction" in other specs. > So the idea is that when contenteditable area is modified by user input, > UA automatically puts something to the transaction history? Right. - Ryosuke
Received on Thursday, 12 April 2012 10:27:01 UTC