Re: [w3c/editing] Removal of browser built-in Undo stack functionality from contenteditable (#150)

> Well, what I did to circumvent that was creating an iframe with a designMode = 'on' document inside. This way I have a separate Undo stack for an editor.

Note that WebKit famously (?) does not have a undo stack per document. Safari's undo stack is shared across all the documents. In general, the behavior about undo/redo isn't really standardized and diverges across platforms.

A while ago, Google proposed on a real [UndoManager API](https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html) (I say Google because I was working at Google at the time) but it didn't get much traction due to its immense complexity, etc...

@whsieh and I are experimenting with something simpler where you can just register a function for undo / redo. I think real-time collaborating editing is a challenging case regardless because what you may have been previously undoable may no longer become undoable at some point.

However, we believe having some good undo / redo on the Web is important since undo / redo is one of the most frequently used feature for any real productivity app, and not having any browser integration would mean that assistant technology (for accessibility) can't even recognize that there is something undoable. It's a freaking embarrassment that we don't have one in 2019.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/150#issuecomment-460017310