
Why ContentEditable is Terrible (2014) - aaronbrethorst
https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480#.mqvm5uq1o
======
barbarian
My business depends heavily on rich HTML editing
([https://qwilr.com](https://qwilr.com)) - and I can't begin to explain how
much time and energy and engineering resource we've poured into trying to
improve that experience, and make it reliable across browsers.

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.

#totally-selfishly-motivated-whining-complete.

------
bograt
I don't accepts axiom 1 as valid.

    
    
      1. The mapping between DOM content and Visible content should be well-behaved.
    

I don't see why the same edit, applied to two documents with visually
identical renderings, should again produce two identical renders.

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'.

~~~
evincarofautumn
That’s not the same edit. In one case, you’re appending to the document. In
the other, you’re appending to a child element. However, appending “a fallacy”
to the document in both cases would produce different results due to text
positioning.

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.

------
jwmerrill
Beautiful description.

Marijn Haverbeke has been writing some great material about his experiences
creating ProseMirror [1]. I wonder how the two systems compare.

[1] [http://prosemirror.net/](http://prosemirror.net/)

[2] [http://marijnhaverbeke.nl/blog/collaborative-
editing.html](http://marijnhaverbeke.nl/blog/collaborative-editing.html)

------
spankalee
With the Range and Selection APIs, contenteditable is almost not necessary
anymore. It still requires a ton of work on top of them to build a decent
editor, but it should be mostly possible now at least.

------
marknadal
I spent half a year reimplementing what should be a native browser behavior,
and it is currently used in production at a company with 100k+ users.

[https://github.com/amark/monotype](https://github.com/amark/monotype)

It solves some enormous headaches, yet is NOT an editor, but a replacement to
selection and range APIs.

------
praxxis
mobiledoc sounds like an open source implementation of some of these ideas:
[https://github.com/bustlelabs/mobiledoc-
kit](https://github.com/bustlelabs/mobiledoc-kit)

~~~
eloisant
That looks nice, but how can I use it?

Is there a .js file I can drop somewhere, or can I use npm+browserify to
include it as a module?

~~~
mixonic
Matt here, one of the folks working on Mobiledoc and the related editor. This
blog post definitely served as early inspiration for our work. I dare to say
we do a number of things better than medium now.

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:

[https://github.com/bustlelabs/ember-mobiledoc-
editor](https://github.com/bustlelabs/ember-mobiledoc-editor)

