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

> Right, this is likely to be implementation-dependent behavior like focus and selection.

Implementation as in "webpage app implementation" or as in "UA implementation"? As far as I can tell, all these JS editors on all the platforms, have separate undo stacks for each input field.

We may need to look at that a bit more in details: Some of these apps are "forced" to have a separate undo stack, because the current one is useless. This would be the case for the smaller editors that can be one of several components on a webpage. The other ones "voluntarily" have separate undo stacks. This would be the case of the bigger webapps that fill the entire page with various input boxes which they all all control. They could have created one global undo stack for all their input fields, but instead they chose to have separate undo stacks for each input field - this is the case with the various products of Microsoft, Apple, Google, etc. .

The big question is here: Would there be simple a richtext editor that would prefer the global undo stack, if they could? From their responses, I haven't come across such an editor project, but that doesn't mean they don't exist.

In any case, we should plan for the separate undo stack, because this seems to be the main usecase and defacto standard as of now.

If the undo manager can be adjusted to accommodate for local undo stacks and be implementable -- that's great. The question is then just what the advantage for the web developer would be to use this undo manager. If the web developer can add two "fake" edit operations to an undo stack that is local to just one element, so that the undo/redo buttons are shown, and then intercepts all edit operations with beforeinput, that should work without contaminating the global undo stack, right?

Personally I wouldn't mind using a built-in undo manager. But as soon as it restricts me in any way even with a more exotic operation, I would likely away from it rather immediately, at least if there is no perceived advantage with using it.

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