Developer's Field Notes
Building an Impossible Rich Text Editor
Rich Text Editors are Impossible to build. I'm trying anyway.
Since I've started building CMS websites for clients more years ago than a care to count, the biggest hurtle has been giving content creators an rich-text editing experience that meets both our needs. For the uninitiated, rich-text editors are the web page fields that allow you to create HTML content (for example when writing social post or editing a page within a content management system) without actually knowing HTML or asking a coder for help.
The rich-text experience has gotten better over the past ten years, especially when it comes to copy-pasting content from word processors. But I'm still finding online editors to be the biggest pain point in delivering a great experience for users.
What makes a RTE seemingly impossible to build? Originally, HTML was meant to be a simple markup language, much like how Markdown is promoted today. And in the beginning, it was. Back in the mid-nineties, a complete tutorial was about 10 pages long and could be mastered in a couple of hours. The current HTML Standard is over 1500 pages, and this isn't including CSS or other Web APIs.
An RTE involves hosting an HTML editor inside another HTML document. That requires handling all the complexity of that 1500 page specification along with anything a user might paste into the editor.
These field notes are a record of me trying to build an experimental rich-text editor to scratch my particular itches.
What a modern RTE should have
Here are a few of my ideas....
Side-by-side source code and rendered views I'm quite tired of jumping back and forth from the source view and rendered HTML text. So often am I switching views while creating particular layouts or verifying custom editor features, I feel that a side-by-side view would be a great feature. Some RTEs don't have a source view at all.
Importing front-end styles into HTML view Content creators deserve a true WYSIWYG experience. To provide this, most RTEs require the developer to provide a second css stylesheet just for the editor that mimics a subset of the front-end site's styles. The issues arise when changes to one stylesheet are not copied over to the other. Most every large project now breaks up it's styles into smaller, easy to manage, documents. So it should not be an issue to place all shared styles into one file, but I'm not seeing it done.
Support for responsive images and <Picture> elements It's 2026, yet editors still only offer users images at a single size.
What the web platform provides
Let's begin by seeing what the web platform provides us to build a modern RTE. Below are the browser features I'm looking to use.
The contenteditable attribute: adding this attribute to a div instantly turns it intro a simple RTE that can be extended by JS.
Web components with shadow root: the web components API makes it simple to create portable HTML elements that are easily added to any web page. These components also encapsulate their contents from the rest of the page which should allow us to apply custom styles without interference from the outer document.
Web Assembly?: If the editor starts to get bogged down by size, moving from plain JavaScript to Web Assembly might provide a big boost in both loading time and performance.
John O'Donnell - Developer
I am a full-stack web developer and founder of Critical Mash. I work with marketing teams to create great CMS experiences.