I suddenly understand the upcoming undoManager

[Izak Burger]

Hi all,

I think I have just gained an understanding of the undoManager that was due to become part of html5 but got pulled out at the last minute. An implementation of this has since landed in Chrome and Firefox (though chrome 32 does not seem to have it, I think you need at least 34).

The undoManager is not unlike many undo stacks you can find on the internet, but unfortunately it does not magically solve the problem. I'll explain the realisation I had a little later :-)

What I've come to understand is that undo is really easy when you're working with simple text inputs, but it becomes complex when dealing with something that is contentEditable. This is because several changes make up a change, and precisely what they are isn't easy to discern in the general case. With things like semantic blocks, attributes and nodes are added and removed all over the entire dom (as it graphically indicates the drop targets), essentially modifying the entire tree in several places, while only really adding one div at the end.

Simple solutions, like waiting for 2 seconds of idleness, always ends up blocking too much stuff into one change.

The only sure-fire way to know how to package modifications for later replay, is for the application to clearly indicate the boundaries. In other words, it has to be done in a way that resembles transactions.

Yesterday I spent some time looking into the undoManager. Initially I was a little dismayed, as all this really does is provide another stack onto which you push transactions. It is not clever enough to magically block the changes.

But today I realised what makes it useful: You will notice that in most browsers, undo on simple textual changes works really well. Hit ctrl+z in anywhere and the last bit of text you typed is undone in exactly the way you would expect it. But ctrl+Z does not work for structural changes performed by scripts, for example, our semantic blocks. This is where the undoManager comes in. By involving the undoManager in during the creation of the block, it now knows how to undo it.

This means that one possible solution -- which unfortunately requires very new browsers -- is to modify the plugins that we use to involve the undoManager where available. This way, whenever you hit ctrl+z (or execCommand('undo') in a script) it can use the information you provided to undo things.

I spent way too much time coming to this conclusion, but I'm thinking perhaps a proof of concept in the semantic block/math plugins will show us if this is the way to go.

regards,

Izak

[Izak Burger]

Here is a description of the problem cases that the undoManager is supposed to help solve. It also mentions collaboration: you don't want to undo someone else's collaborative edit when you hit undo :-)

http://www.w3.org/wiki/Web_Editing_APIs/UndoManager_Problem_Descriptions