<story><title>Why ContentEditable Is Terrible, Or: How the Medium Editor Works (2014)</title><url>https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480</url></story><parent_chain></parent_chain><comment><author>morgante</author><text>This article was very inspirational for me when developing the CMS for a previous startup and informed that development extensively.&lt;p&gt;Personally, I found the most beneficial thing to be abandoning HTML entirely. Instead I developed a JSON data structure for documents which was stored internally. This is very powerful for a couple of reasons:&lt;p&gt;1. Any user input can be mapped as pure functions on top of your internal document structure. This way you can also enforce business rules easily. Additionally, any function which you don&amp;#x27;t support will &lt;i&gt;never&lt;/i&gt; occur. (No more Word garbage!) ContentEditable works fine as an &lt;i&gt;input&lt;/i&gt; though.&lt;p&gt;2. You can write functionally pure mappings from your internal structure to other formats. This of course includes HTML, but isn&amp;#x27;t exclusive to HTML. Content can also be mapped into native mobile components as well.&lt;p&gt;3. You can be flexible with input types. For example, it was fairly trivial to (for fun) add a Markdown mode which would map any Markdown input onto the internal document representation and then back to Markdown.&lt;p&gt;4. You can introduce new semantic concepts which HTML doesn&amp;#x27;t have elements for, like a &amp;quot;quiz.&amp;quot; This makes it easy to rejigger the display of such elements later on, or to have the same semantic element render completely differently on mobile and desktop (for example). With HTML, you&amp;#x27;re stuck doing error-prone tree parsing or Regexes.</text></comment>
<story><title>Why ContentEditable Is Terrible, Or: How the Medium Editor Works (2014)</title><url>https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480</url></story><parent_chain></parent_chain><comment><author>georgestephanis</author><text>Yup.  Wysiwygs are hard.  But just saying &amp;quot;You can edit paragraphs, that&amp;#x27;s all you get&amp;quot; is worse.  Clients need to be able to do more advanced things in an editor, and coding a hard limit on never being able to do them feels like pure folly.&lt;p&gt;Is TinyMCE perfect?  Far from it.  But it&amp;#x27;s stable and reliable across browsers, with a well-defined API, and it gets the job done.&lt;p&gt;I know a lot of folks here would just as soon just use Markdown for all content writing.  I like Markdown.  Clients hate it.  It feels like an obscure language, when they just want something &amp;quot;like Microsoft Word&amp;quot;.&lt;p&gt;And CMS&amp;#x27;s can hardly say &amp;quot;Yeah, we know we used to support these greater markup sets, but now we&amp;#x27;re just not going to, so don&amp;#x27;t open up your old posts, or they&amp;#x27;re going to lose some content in our bright shiny new editor&amp;quot; -- that&amp;#x27;s massively problematic as well for user trust.&lt;p&gt;If you&amp;#x27;re starting something new, and want to place a hard cap on what your users can do markup-wise, sure, give this a shot.  But be very aware of the restrictions that you&amp;#x27;re imposing.</text></comment>