Rich text editors and rendering engines

Everyone who&#x27;s ever build on top of contenteditable has war stories, my first bash with it was about 19 years ago. But tools like Prosemirror and Lixical solve most of those issues and separate the content from the presentation. 99% of the time they do what you want, but that 1% is impossible (page breaks!). Personally I&#x27;m a fan of TipTap, it&#x27;s a great abstraction over the lower level complexities of Prosemirror. The TipTap&#x2F;ProseMirror&#x2F;Yjs combination is insanely good for being able to build collaborative editing.<p>Amused by the nod to the Ladybird WASM idea at the end, I&#x27;m taking credit for that: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35521878">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35521878</a>. Good ideas spread. (Joe, apologies for not getting back to your email, it&#x27;s been a rather busy few months)

Why does this website use spans and weird javascript to fake links, instead of normal a tags? It means that right-click to open in a new tab doesn&#x27;t work. Very strange. And very irritating.

I once tried to build an editor for collaboratively writing fiction. I used contenteditable&#x27;s.<p>I think that was the most humbling programming experience of my life. I gave up after a few weeks of banging my head against the wall.

And every time you use something custom, you end up breaking things for users you can&#x27;t even imagine. Even when you think you have all the edge case covered.<p>Like I use a custom DefaultKeyBinding.dict for my laptop using which I&#x27;ve defined some shortcuts for text editing. It works with Textarea but not for GDocs. Which makes editing so cumbersome for me.<p>I&#x27;ve always wondered why this was the issue until I read this article. Now I see why it&#x27;s broken.

Rich text editing doesn&#x27;t imply pagination. Contenteditable is not abandoned. Lexical[1], Meta&#x27;s framework for text editing relies on contenteditables.<p>[1]: <a href="https:&#x2F;&#x2F;lexical.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;lexical.dev&#x2F;</a>

He alludes to the reason why it’s like this at the very end… google and Microsoft see it as their competitive advantage, so they have no reason to collaborate, but guess who also makes the two most popular browsers… so not only do the companies that have made great improvements compared to contenteditable have no reason to collab on making a new standard, those two companies have a very big reason to never improve the APIs in their own browsers.<p>Another reason our activist FTC head should focus her sights on Google after she’s done pulling Amazon apart.

contenteditable may have its flaws, but I&#x27;m not sure if it&#x27;s fair to call it &quot;abandoned&quot; as browser vendors do still maintain it - for example this very week Firefox 115 came out and the release notes[1] refer to updates to how contenteditable works.<p>[1] <a href="https:&#x2F;&#x2F;www.mozilla.org&#x2F;en-US&#x2F;firefox&#x2F;115.0&#x2F;releasenotes&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.mozilla.org&#x2F;en-US&#x2F;firefox&#x2F;115.0&#x2F;releasenotes&#x2F;</a>

This is both fascinating and sad. It does feel somewhat reminiscent to the state of HTML (pre-HTML5) before W3C and WHATWG agreed to work together on the development of HTML5. I suppose Google, Microsoft, Zoho, and other large companies that have implemented their own their own layout systems consider their implementation a competitive advantage and would not find it worth the effort to collaborate on a new standard to supplant contenteditable — if that is even possible.

A bit of a tangential question ...<p>If one were to write a simple text editor from scratch - is there some place with a &quot;spec&quot; or list of standard modern text editor UI paradigms one would need to implement to make the editor feel natural&#x2F;normal ? (so it feels like Kate&#x2F;GEdit&#x2F;contenteditable)<p>I kinda get there are a lot of little subtle quirks and corner cases that need to be covered so it doesnt feel weird or janky<p>For instance EMACS CUA-mode is an example of a incredibly incomplete implemention

Some parts of a web browser are generally useful for applications. The APIs that control how the application interfaces with the host operating system, security, networking, etc. But the parts of a browser that deal with actual content are often problematic.<p>As a casual user of HTML and CSS, I&#x27;m often struck by how stupid the layout controls are. How very simple things (&quot;centering text&quot;) are often confusing and difficult. And it&#x27;s striking how these layout and content limitations make it necessary to add layer after layer of complexity (mostly in the form of JavaScript and CSS) in order for anyone to make a &quot;modern&quot; web page successfully. Whereas older applications that are not &quot;web-based&quot; allow any casual user to create rich document presentation just by pointing and clicking.<p>The Web today is like an Indy 500 race car with foot petals. I think we need to consider the future and how we want computers to work, and start moving towards that, rather than perpetually carrying forward the status quo.

I think the OP is kinda off the mark. The next step for web editor abstractions is not implementing layout engines so we can render page breaks correctly. It’s a library that separates <i>handling input</i> from <i>rendering output</i>. The biggest constricting factor with ContentEditable is that your <i>rendered view</i> also dictates how your input works. We need a library that handles all the user interaction and accessible, localized text input flawlessly but invisibly while integrating well with the OS. If we have that, developers can build their layout system on top or just use DOM layout without worrying about their DOM structure being compatible with ContentEditable input quirks across all the browsers, or their HTML changing in random ways under their feet.<p>There are a lot of problems with doing a hidden ContentEditable for input, which is what Google Docs does. Last time I looked, the input &#x2F; focused DOM element was actually hidden <i>inside</i> the blinking caret. But that strategy is clumsy with assistive technology because the accessible bits don’t “line up” with the actual UI drawn to the screen. It also breaks some system conventions like smooth cursor movement when holding spacebar on iOS’s keyboard. You can try it in Google Docs and see what I mean.<p>Those kinds of issues are actually why Lexical (FB’s new text editor toolkit) doesn’t use hidden input according to Lexical’s author trueadm on Twitter (can’t find my citation). Those same issues also make us hesitate to move that direction in Notion’s editor.<p>If you want to use a custom “layout engine” implemented on top of the DOM today, you can use Skia CanvasKit (<a href="https:&#x2F;&#x2F;skia.org&#x2F;docs&#x2F;user&#x2F;modules&#x2F;quickstart&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;skia.org&#x2F;docs&#x2F;user&#x2F;modules&#x2F;quickstart&#x2F;</a>) or Flutter Web which is based on Skia. Although CanvasKit is kinda slow and text looks bad on iOS.

&gt; Google Docs uses its own layouting system for its editor---which means, it doesn’t use browser’s contenteditable API<p>Ah!, so that&#x27;s the reason why copy-paste is badly broken in google docs (and jupyter notebooks as well)? Now I understand the reason. It&#x27;s because they didn&#x27;t reimplement it again.<p>I can copy-paste between all my windows and firefox tabs, <i>except</i> google docs and jupyter notebooks. This is because the selection that they show it&#x27;s not an actual text selection that the system understands, but just a hand-drawn color rectangle around the text. It&#x27;s a fake selection, of sorts!

An alternative to contenteditable is to use a plain &lt;textarea&gt;, measure the inline width of the rendered text to get the absolute position of each word, and then overlay styles on top.<p>You need to debounce&#x2F;throttle the change event handler to not fire too many re renders when typing.<p>I used this approach for <a href="https:&#x2F;&#x2F;bigwav.app" rel="nofollow noreferrer">https:&#x2F;&#x2F;bigwav.app</a> for highlighting text.<p>You can click the demo .bigwav file to take a look.

Simple RTF editors are surprisingly few. The AbiWord project looked promising but the MS Windows version ceased development and other versions didn&#x27;t get much love. I&#x27;m surprised that even a lightweight RTF editor has difficulty finding a place.

I feel the pain of this author, but between stuff like pell.js and more and more web devs understanding and taking advantage of template literals for rendering, we&#x27;re not really far off from what is being described.

A perfect example of the limits of HTML rendering. It works for a large class of applications, but it&#x27;s not the end of the line in terms of all UI.