Re: [w3c/editing] undo manager (#209)

@scofalik I think we are discussing realtime editors here to see if this proposal will work for that usecase because it is sort of the most complex thing we are doing in relation to undo/redo, I think. The conclusion so far seems to be that - yes, even for that usecase it will work, and the spec will represent a significant improvement over the current situation (we would just add either zero or one undo/redo events so that the buttons enable/disable as needed), but it only works because we would be using the new features to enable/disable the undo/redo buttons as we need them and not as the spec intends us to do. If the browser makers are ok with (ab)using it like that and don't just want to give us a more direct way to enable/disable then I think we should support this.

As for the shifting number of undo steps - yes, you did finally get me. Building an editor where you can undo the changes of your collaborator (or enemy) could also be a fun challenge, but probably not something for realworld usage. :)

Even if this is not used as intended for the main editor, it may be an improvement for the various side editors that web apps can have. Like a modal with a form with five different form fields can have it's own unique undo history that goes across input/textarea. 

-- 
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/209#issuecomment-531815572