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

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

> We're fine with having that as an option but forcing that on all contenteditable content is definitely not okay for us.

Great! Then we are in full agreement.

Then we just need to figure out how to do it in combination with the beforeinput system and the inputTypes undo and redo. Say we simply combine beforeinput with a future undomanager that always for the insertion of arbitrary JS objects to be stored with the undo entry. Undert these circumstances, what kind of data should we get in the beforeinput events for undo and redo? Should we simply get access to the item in the undo stack that would be applied if we don't preventDefault it?

And can we have an intermediate solution until we get the undo manager so that we can ensure that undo and redo always are enabled when we need them to? Or should we just say that JS developers simply need to use a hack as I posted above, in the meantime?

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