[whatwg] Fixing undo on the Web - UndoManager and Transaction

On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>
> Though I guess you can always supply the same function for apply and
> reapply, but that means you can't use the convenient inline syntax
> that you've used in your examples.
>
> Or does 'reapply' default to the 'apply' function if it's not provided?
>

Yes.  That's the plan.  I guess I left that detail out?

 >> For the record, my vision was that the editor will keep track of the
> >> mutations *it* does to the DOM and inserts managed transactions for
> >> those into the UndoManager.
> >
> > Did you mean manual transactions?
>
> No. What I mean by "editor" above is the UA code which responds to
> keyboard events and modifies the DOM based on those. I.e. the code
> implementing @contenteditable.
>
> I hope that makes things more clear.
>

Oh, yes definitely.  The UA will keep track of mutations they made in order
to unapply and reapply those managed transactions.

 I think such an event (or set of events) is needed anyway in order to
> let people implement their own tweaks on the @contenteditable
> implementation.


Right.

> But there are cases where the script wants to let the
> > user agent modify the DOM, and then learn what it did instead of
> preventing
> > the default action and manually simulating it because the latter involves
> a
> > lot of work.
>
> Can you give examples?
>

e.g. in a simple collaborative editing app, you may want to let UA implement
basic editing operations even though you want control over the undo
transaction history and need to tweak markup afterwards.

For example in the collaborative editing case I would think that the
> page generally wants to get a semantic understanding of the editing
> operations so that it can reapply them even if the DOM looks somewhat
> different when an action is redone. I.e. even if someone else has
> edited the page by the time the action is redone.
>

You're right that you can redo what the UA did after you unapplied the
managed transaction UA inserted.  So maybe "replace" isn't really that
useful after all.  But I had an impression that having to "replay" UA's DOM
changes is annoying.  But getting rid of "replace" will certainly make the
API simpler, and we might able to address the latter concern by introducing
a function that take a mutation list and re-applies it.

If it's needed for other reasons too, then of course we should. But
> I'd like to understand those other reasons.
>

e.g. some apps may want to use br instead of p or div for paragraph
separator.  And there might be some custom UI that shows up around the
inserted text.

- Ryosuke

Received on Friday, 5 August 2011 17:17:17 UTC