We had an enormous leg up in that effort - the guy who built the Google Wave editor helped us design and build the core of our editor; even so, its been this massive thorn in our side. Its been months and we still haven't gotten our custom editor out into production for all users (just a beta testing subset at this point).
I recognise of course the myriad competing forces for engineering time on the browser vendors ("implement X new shiny API!") - but O how I wish they would agree upon / build a rock solid content-editable experience.
1. The mapping between DOM content and Visible content should be well-behaved.
As a simple example, take document (a) consisting of the words 'an axiom' styled white on a white background, and document (b) an empty document with default styling of black text on a white background. Both would appear blank.
Now apply an edit, say inserting the text 'a fallacy' into both documents. After the edit, document (a) can be expected to remain blank while document (b) can be expected to show 'a fallacy'.
I think if you want #1, you need an isomorphism between documents and their appearance. This article only asks for a homomorphism, where different documents are allowed to produce the same result.
Marijn Haverbeke has been writing some great material about his experiences creating ProseMirror . I wonder how the two systems compare.
It solves some enormous headaches, yet is NOT an editor, but a replacement to selection and range APIs.
Is there a .js file I can drop somewhere, or can I use npm+browserify to include it as a module?
Mobiledc-kit is on npm as amd and es6. I believe also as CommonJS for browserify, but open an issue if it isn't.
If you use Ember, this add-on provides a more complete UI: