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

>>Not quite. This would still break semantics of the shared undo stack across documents.

> The global undo stack is already broken as it is -- in all of the web apps, because it's global, because changes are added via JS, etc. . As long as contenteditable adds items to this global undo stack, it will be broken.

The other option, and this is what was proposed by Chrome and Edge representatives at the F2F, was to exclude contenteeditable from the global history and add a way to enable/disable the undo/redo menu entries so that the editor can receive the corresponding beforeinput event.

That is of course a much cleaner solution as it doesn't interfere with the global undo stack used by other fields. I opened this issue primarily to figure out if there is actually no use for the global undo stack at all. And there I found the draft-js issue which probably needs further investigation.

Now if Safari cannot do what was proposed by the other browser vendors, then we need a solution for that. At this early stage, it maybe enough to find a JS hack to get around the disabled undo/redo menu items. At the next stage, I would think it would make sense to find some less hacky solution, but we can talk about it at that time.

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