Why ContentEditable is Terrible (2014) | Hacker News Reader

Why ContentEditable is Terrible (2014)

medium.com

My business depends heavily on rich HTML editing (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.

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

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.

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/

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

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.

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

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

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

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?

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

Reply on news.ycombinator.com