[whatwg] Random comments about UndoManager

Ryosuke Niwa rniwa at webkit.org
Thu Apr 12 10:27:01 PDT 2012

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

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?


- Ryosuke

More information about the whatwg mailing list