-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to make 'undo'/'redo' useful #36
Comments
From the JS perspective: Interrupting CTRL+Z is not that difficult and is what can be done now, so unless we offer something just as simple, JS editors will likely continue with that.
This would solve one thing in relation to what we have today: The undo in various menus would be enabled and the user making use of those menus could be handled the same way that ctrl+z would be handled. But: also the JS editor history will be of limited length. There will be times when there is nothing to redo (so 'redo' should be disabled) or nothing to undo (so 'undo' should be disabled). If these elements are "always enabled" in the menus, then that seems slightly wrong. If we have a way to dynamically enable and disable features from the editor, then that might work. |
Yep, but it won't work if you have multiple input fields on the same |
True. But also, if JS interrupts any of the editing operations of any of the editors, the browser-internal history won't be usable. Right? |
Ctrl+Z doesn't exist on iOS yet iOS definitely supports undo. I once wrote an undo manager API: https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html The challenge here is that WebKit must use AppKit's NSUndoManager behind the scene, which means that we can't simply enable/disable undo/redo menu. We actually need an undo/redo item in our undo stack. |
Testing Google Docs main editor and title input field: The history is handled separately for each of them. If the caret is in the main editor, only the edits in that editor are undone. If in the title field, only changes in that input field are undone. Testing in Office 365 with a comment and text in the main editor, the same behavior applies. This mirrors the behavior of how the various JS editors that are not maintained by browser makers are handling undo on a per-editor basis. A global edit history for the page doesn't really seem to be of interest to those creating such editors. If we want to preserve this global undo stack for other, unhandled areas, such as input fields, etc., maybe we can add some option for the browser to entirely ignore a specific contenteditable area when it comes to editing history?
@rniwa: Would there be a practical way of faking it? Given that the JS editor will have to handle undo/redo itself anyway, what would the most practical way be to achieve that on iOS? |
Really, the only practical way is for web apps to be inserting undo/redo items onto the browser's undo stack. |
@rniwa That sounds like an unfortunate coupling. I guess one could add dummy items into the clipboard (?) and then only use that system on iOS. Is it possible to add and remove an arbitrary number of such dummy items? |
Although there is no formal resolution ( Alternatively, there is a hack to achieve this in JavaScript in Chrome and Firefox: w3c/editing#150 (comment) Apple has later declared that it will not support a switch to turn on the editing menu when the browser's history is empty. Instead it will wait for the creation of a global undo stack manager. There is a draft spec from 2012: https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html . Correct @rniwa ? |
@Reinmar: Would this code snippet make the beforeinput events for undo/redo work for you while we are waiting for some more complex undo manager some time in the future? w3c/editing#150 (comment) |
Background
Currently
'undo'
/'redo'
is targeting the Element to be modified (but not the focused Element)Issues
'undo'
if it prevents all'beforeinput'
'undo'
will be fired if the stack is emptySolution
'undo'
entries into the stack (with'target'
)Or alternately:
'undo'
/'redo'
as always enableddocument
if the stack is empty'undo'
/'redo'
fromdocument
The text was updated successfully, but these errors were encountered: