Open johanneswilm opened 1 year ago
I see for example the undo feature is broken in editor.js and that is at least in part due to allowing native browser actions/execcommand. If I do this sequence in the demo editor:
Mark a word as bold.
Hit enter somewhere in the paragraph to split the paragraph in two.
Right click and choose "undo"
Expected behavior: The paragraph split is reverted. Alternatively: nothing happens.
What actually happens: The word is unbolded. Second click on undo makes the second half of the paragraph disappear.
I have spent the past ten years working on the W3C specs related to editing. We put a big notification in the execCommand document to communicate that one should not use it. That's because a lot of projects in the past started using the execCommand spect and wasted years of their lives on that only to discover that they had to redo everything in order to make it stable.
As far as I can tell, editor.js is only using a limited amount of execCommand, so you may be lucky and it's possible to remove the last bits without investing a lot more resources on this.
If you split text by pressing enter and try to undo it, it will break it seems like a problem with undo itself
@Ice-mourne That is true. However by avoiding using execcommand and native dom changes, you avoid adding items not the undo stack and therefore avoid having users lose their texts.
This has been discussed previously in https://github.com/codex-team/editor.js/issues/2211 .
The Input events spec has in fact been implemented in every browser (Chrome, Webkit, Firefox) and has been shipped for several years already. All the main editors (ProseMirror, Trix, CKEditor 5, etc.) have stopped using execCommand several years ago. Even without input events, there are better ways of achieving the same as one can do with execCommand.