Developing the Rich Text Editor for DeepL.com

Why did DeepL build its own rich text editor? The answer reveals the hidden complexities of `contentEditable`, from cursor management to messy clipboard data.

#1about 3 minutes

Why DeepL needed a custom rich text editor

Standard HTML textareas are insufficient for advanced features like word suggestions, rich text formatting, and visual diffs for the writing assistant.

#2about 4 minutes

The decision to build the DTextArea component

DeepL chose to build its own component to meet specific requirements like full customizability, a separate visual layer, and synchronized text areas.

#3about 1 minute

Using a virtual DOM for text representation

The editor uses a custom, minimal tree structure inspired by the DOM to represent text content and a separate visual layer for highlights.

#4about 6 minutes

The surprising complexity of handling line breaks

Line breaks are often implied by the HTML structure rather than explicit, requiring the editor to perfectly mimic inconsistent browser behavior.

#5about 6 minutes

Managing cursor position in a volatile DOM

To prevent the cursor from jumping during DOM cleanup, its position is converted from a node-offset pair to a stable character offset and back.

#6about 2 minutes

Supporting the Input Method Editor for non-latin languages

The Input Method Editor (IME) for languages like Japanese can break if the DOM is modified, requiring the editor to pause manipulations during composition.

#7about 4 minutes

Navigating browser bugs and external content issues

Challenges include browsers generating invalid HTML, inconsistent event orders, interference from browser plugins, and sanitizing complex clipboard content from apps like Microsoft Word.

#8about 2 minutes