I am the author a recently-launched similar product [1], which also tries to contain the impact of contentEditable by capturing user actions and applying them t

I am the author a recently-launched similar product [1], which also tries to contain the impact of contentEditable by capturing user actions and applying them to the document model in its own code. The main difference is that my system does leave selection (mostly) to the browser, by enabling contentEditable and then capturing events that actually perform changes. Another project of mine [2] does take the approach taken by Ritzy, but for plain-text editing. I consciously didn't go that way this time. Here's why: - Accessibility. Screen readers don't know what you are doing if the browser doesn't know. They won't communicate your tag soup to the user as an editor interface. - Cursor motion and selection management hard. Consider right-to-left text and mixed bidirectional text. Getting this right is a big project on its own. You can get the basics working easily, but there's a long tail of hard behavior that you will at some point need. - Touch interfaces don't interface well with your fake selection. So you'll have to implement your own selection-management interface. Which might not even be possible for some things (like access to the built-in spell checker). - It isn't needed. Though it also requires some gymnastics, working with the browser's native selection on modern browsers isn't all that hard. [1]: http://prosemirror.net http://prosemirror.net [2]: http://codemirror.net http://codemirror.net