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

As for 2 I don't think one needs to worry about those that come from entirely browser controlled elements. The browser will simply take care of those by itself and the JS editor doesn't even have to know they happen. Or why would you want to add those steps to your own undo stack as well?

But your comment makes me think that there will likely be cases where the browser tries to auto-add items to the undo stack for the JS controlled element and in the scenario where one actually wants to let the browser maintain the order of undo steps (the no tricks version hwere it's part of a form together with input fields, etc.), that will likely in most cases lead to annoying issues of the browser having added items to the undo stack that shouldn't be there because the editor also adds it to its own undo stack. 

Take for example text input - each character will likely add an item to the undo stack with the merge flag set while the same word is being typed and then without it being set for the next word. The problem is that JS editor and browser may disagree about what constitutes a word, etc. .

So I think that your proposal of having a listener there to then be able to stop specific items from entering the history or, alternatively, a way to simply stop the browser from trying to auto-add any items to the undo stack for a given contenteditable element would likely be helpful.

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