[whatwg] Feedback on UndoManager spec

Okay, I created a wiki page with use-cases and requirements for them:

http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions

I based it off http://rniwa.com/editing/undomanager-usecases.html,
plus posts in this thread.  I think that the current spec does not
fulfill the following requirements that I suggest on that page:

* "The author must not be forced to deal with manually handling DOM
state just because they want to handle non-DOM state."  Currently, if
I want the UA to automatically handle DOM state, I cannot provide
unapply or reapply methods.  This means that if I need to handle
non-DOM state, like for a canvas editor, then I have to keep track of
all my DOM changes too.  I should be able to write a canvas editor and
still let the UA handle all DOM state.  This would mean allowing
unapply/reapply methods to be provided for automatic transactions,
with the UA undoing any DOM changes they cause.

* "If browsers try to merge changes themselves, the algorithm should
be well-defined if possible. Otherwise it will just confuse authors
and not be useful, because it will succeed in some browsers and fail
in others, or have unpredictable results."  The current spec doesn't
solve this requirement, but it might not be solvable.  I discuss that
further below.

Does anyone disagree with any of the requirements on that page, or
think that there are any more requirements that need to be added?  I
think all that should happen at this point is allowing unapply/reapply
to be supplied for automatic transactions, but make sure that any DOM
changes they make are undone immediately so that the DOM doesn't fall
out of sync.  That solves one of the two requirements that (IMO) the
current spec doesn't meet.

On Mon, Nov 7, 2011 at 11:55 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> I don't understand what problem(s) you're trying to solve here. Even if we
> introduced noundo content attribute, there's nothing that prevents authors
> from not using that content attribute and modifying DOM directly.

Okay, thanks.  This is the key point I was missing.  Just so I
understand, what's supposed to happen here:

* Some changes get made in an automatic transaction.
* Some changes get made in no transaction at all, just a script
calling DOM methods.
* execCommand("undo")

Is the resulting DOM just undefined?  Why isn't it defined to be
whatever the state was before the automatic transaction, so any
intervening changes just get undone too?  This seems to be what Gecko
does.  E.g.:

data:text/html,<!doctype html>
<div contenteditable>Foo</div>
<script>
var div = document.querySelector("div");
getSelection().selectAllChildren(div);
document.execCommand("bold");
div.innerHTML = "bar";
document.execCommand("undo");
</script>

Firefox 9.0a2 produces the results I expected, i.e., "Foo" selected
and not bolded.  Chrome 16 dev re-adds the removed "Foo", then unbolds
and selects it, so you get "bar[Foo]".  Opera Next 11.50 just ignores
the undo.

Now consider this:

data:text/html,<!doctype html>
<div contenteditable>Foo</div>
<script>
var div = document.querySelector("div");
getSelection().selectAllChildren(div);
document.execCommand("bold");
document.body.appendChild(document.createTextNode("bar"));
document.execCommand("undo");
</script>

Opera seems to just ignore the undo.  Chrome tries to cleverly merge
it, and in this case succeeds, unbolding "Foo" without removing the
"bar".  Firefox removes "bar" and also unbolds "Foo", so again, it
just restores the whole page's DOM state to what it was before the
transaction it undoes.

It looks like what Gecko does is include *any* DOM changes anywhere in
the page automatically in the previous transaction.  This makes sense
to me, and it guarantees that changes can always be undone reliably.
Is Gecko's behavior here bad?  What disadvantages does it have?  Can
we work around those disadvantages while still meeting all use-cases,
and keeping behavior performant *and* well-defined?

> Also, this noundo content attribute will be problematic inside
> contenteditable region because random elements that need to removed/moved
> may have this attribute.

Yes, we'd have to be careful about what happens if the attribute is
added/removed.  However, it should be possible to do that, and then
behavior will be well-defined, which is a big plus.  Obviously, as you
point out, this attribute is only really useful if the UA tracks *all*
DOM changes as part of the last transaction, as Gecko seems to do.
Otherwise it doesn't simplify anything.

> There's out-dated list at?http://rniwa.com/editing/undomanager-usecases.html

Thanks.

Received on Monday, 7 November 2011 12:26:23 UTC