[whatwg] Random comments about UndoManager

[Ryosuke Niwa]

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