W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 5 Aug 2011 19:12:04 -0700
Message-ID: <CA+c2ei_Xid_JfV3JFtaDQswrd1Ah-bBD2L9tozLG08t4GH5ZfQ@mail.gmail.com>
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> 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.

You'll need to be able to "replay" the UA's DOM changes anyway since
you need to redo them if the user "undo"s and "redo"s.

>> 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.

For these I would imagine you cancel the beforeEditingAction event and
do your own DOM modifications.

>?And there might be some custom UI that shows up around the
> inserted text.

For this I wouldn't imagine you want to replace the managed
transaction anyway since you still want to let the UA deal with
undo/redo, right? Instead I'd merge another transaction which adds the
custom UI with the managed one that the UA created.

/ Jonas
Received on Friday, 5 August 2011 19:12:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC