You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wonder if edit context could also support an undo manager (for all the reasons and use cases described in that issue). It looks to me that once you have an edit context, pushing and poping things from the undo/redo stack should be compatible. In a way, it is one more thing which happens between input event and displaying the result in UI.
@mitar I agree that it would be good to somehow be able to enable/disable the undo and redo buttons directly. That should be useful if you have an editor using editContext and beforeinput events as it will allow JavaScript-based editors to easily use these buttons for their own undo stacks.
Creating an entire undo manager on top of it seems like a larger effort that may not bring that much extra to the user. A lot of editing operations will not deal with the editContext at all (for example everything formatting related like bold/underline), so there would have to be an API to add individual items to the stack, and there will possibly also be some editContext operations that should not go onto the undo stack, so there needs to be a way to prevent that.
One could also imagine editors that are only ever enabled for a small part of the content of the page (such as book editors that show the entire book of 150,000 words but only ever enable editing on a few paragraphs at a time to make the page run faster) and then the global undo stack should not obtain editing operations from the edit context at all but would have to rely on the JavaScript to add all of these.
In conclusion, I am not opposed to a browser-based undo-manager if there are concerns from the browser makers about letting JavaScript authors enable the undo and redo buttons directly and use their own undo stack by listening to before input events to these buttons. However, I don't see much of an advantage from the perspective of the user and it sound like a larger project. Alsol, I don't see why this would need to be coupled to editContext as the undo manager would also be helpful for other web applications.
I wonder if edit context could also support an undo manager (for all the reasons and use cases described in that issue). It looks to me that once you have an edit context, pushing and poping things from the undo/redo stack should be compatible. In a way, it is one more thing which happens between input event and displaying the result in UI.
cc @johanneswilm
The text was updated successfully, but these errors were encountered: