Why building a reliable inline rich text editor is still surprisingly hard

#webdev #javascript #frontend #typescript

Rich text editing on the web looks like a solved problem — until you try to build something that works reliably in real-world apps.

On paper, browsers have had contenteditable for years.
In practice, once you start building production features around it, things get weird very fast.

The illusion of “it just works”

Simple demos usually work fine:

Type text
Select text
Click bold
Done
But real users don’t edit like demo users.

They:

Double click words
Triple click paragraphs
Select backwards
Select across multiple nodes
Paste random formatted content
Edit inside nested elements

That’s where things start breaking.

The hardest part isn’t UI — it’s selection

Most of the complexity I’ve seen comes from selection handling:

Different browsers return slightly different selection ranges.
Collapsed selections behave differently.
Multi-node selections are inconsistent.
Toolbar state can easily desync from actual formatting.

And once your toolbar shows the wrong state — users lose trust instantly.

Bundle size vs correctness tradeoff

Many editors solve this by adding layers of abstraction:

Virtual document models

Command pipelines

Large plugin ecosystems

This works — but often at the cost of:

Huge bundle sizes

Slower startup

Harder embedding into existing apps

Sometimes you don’t need a full document engine.
You just need editing to feel predictable.

What I started focusing on instead

While experimenting with editors in real projects, I found myself caring more about:

• Selection normalization across browsers
• Toolbar state always matching real formatting
• Inline editing that feels native
• Small, embeddable footprint

Instead of building “more features”, I tried removing everything non-essential.

What I learned