Documentation editor comparisons evaluate feature checklists: component reuse, conditional content, versioning, multi-channel publishing. They ignore the surface your writers stare at for six to eight hours a day.
Font size, line length, contrast ratio, line height, and visual clutter directly affect comprehension, error rate, and cognitive fatigue. These are measurable variables with peer-reviewed research behind them — not aesthetic preferences.
This article compares that surface across six production editors, graded against the research.
What the Research Says About Line Length, Font Size, and Spacing
Three decades of readability research converge on specific, measurable values for the typographic variables that matter most in sustained reading and writing. These are not design opinions — they are experimental findings with controlled studies, eye-tracking data, and statistically significant sample sizes.
Line length is the single most studied variable. Robert Bringhurst's The Elements of Typographic Style recommends 45 to 75 characters per line for single-column text, with 66 CPL as the ideal. Dyson and Haselgrove, in a 2001 study published in the International Journal of Human-Computer Studies, tested multiple line lengths and found that 55 CPL produced the best comprehension scores, while 100 CPL produced the worst. The Baymard Institute found that product descriptions wider than 80 CPL were skipped 41 percent more often than those in the 60 to 70 range. Google's Material Design guidelines recommend roughly 60 CPL.
For documentation editors, these numbers translate directly to a CSS max-width of approximately 65ch on the content area. If your editor stretches text edge-to-edge on a wide monitor, readers lose their place tracking from the end of one line back to the start of the next — exactly the failure mode Dyson and Haselgrove measured.
Font size has a less obvious but equally documented effect. A 2016 ACM CHI study by Rello, Pielot, and Marcos — 104 participants, eye-tracking validated — showed comprehension significantly improved at 18 points and above. Larger sizes reduced fixation duration, meaning the eye processes each word faster. The browser default of 16px is a minimum for mobile, not a target for sustained desktop reading. Medium uses approximately 21px for body text. iA Writer deliberately uses the largest font size that fits their layout and offers no size control, because they consider the question settled.
Line height occupies a tighter sweet spot than most designers assume. The same Rello study tested spacing from 0.8x to 1.8x font size. Both extremes impaired readability — the optimal range landed at 1.4x to 1.6x, with 1.5x as the practical target. Line height should increase proportionally with line length to help the eye track back to the start of the next line, a relationship most editors ignore by applying a single fixed value regardless of content width.
Paragraph spacing involves a real tradeoff. Chaparro, Baker, Shaikh, Hull, and Brady at Wichita State's Software Usability Research Laboratory measured this directly: participants with more whitespace between paragraphs read slower but comprehended more. Whitespace costs vertical screen space and buys accuracy. Approximately 1.5rem between blocks is the research-supported target.
These four values — line length, font size, line height, and paragraph spacing — interact as a system. Getting one right while ignoring the others produces diminishing returns.
| Parameter | Research range | Practical target |
|---|---|---|
| Line length | 45 to 75 CPL | 55 to 66 CPL (~65ch) |
| Line height | 1.4x to 1.6x | 1.5x |
| Body font size | 16px minimum | 18 to 21px for sustained reading |
| Paragraph spacing | More than 1.0x line height | ~1.5rem |
Contrast and Color: Why Pure Black on Pure White Is Wrong
Documentation teams rarely question text color. Black text on a white background feels like the only option. But full contrast — the 21:1 ratio of #000000 on #FFFFFF — is not optimal for extended reading. It overstimulates the eye during sustained sessions.
The better choice for long-form writing: dark gray text (#333 or #444) on white. This reduces contrast to roughly 12:1 to 9:1, still well above WCAG AA requirements (4.5:1 for normal text), while reducing eye strain over hours of use. Dropbox Paper uses #1b2733, a warm off-black that passes every accessibility standard while being noticeably more comfortable than pure black.
Dark mode introduces a separate problem. Pure white text on pure black causes halation — a glow around letterforms where the bright characters bleed into the dark background. This effect is particularly severe for the roughly 47 percent of people with some degree of astigmatism. The research-backed recommendation for dark mode: off-white text (around #E0E0E0) on dark gray (around #1A1A1A), never #FFF on #000.
Piepenbrock, Mayr, and Buchner, in a 2013 study published in Ergonomics, found a clear positive polarity advantage: dark text on light backgrounds produced better visual acuity and proofreading accuracy than light text on dark backgrounds. The Nielsen Norman Group reports that roughly 33 percent of users consistently prefer light mode for readability, and participants did not self-report differences even when their performance was measurably better in positive polarity.
For documentation teams, the implication is direct: if your writers proofread in dark mode, they will catch fewer errors — even if they do not feel less productive. The editor's default polarity matters more than personal preference might suggest.
Cognitive Load: Toolbars, Menus, and the Cost of Visual Clutter
Every toolbar button your editor displays is an attention tax. This is not metaphor — it is measured.
A 2021 eye-tracking study found that writers using feature-rich editors spent 22 percent of their time scanning UI elements rather than composing text. A separate 127-participant study found that minimal UIs reduced visual cognitive load by 41 percent on the NASA Task Load Index scale, cut task-switching latency by 2.8 seconds, and lowered documentation error rates by 23 percent.
Attention research explains why the cost is so high. Dr. Sophie Leroy's 2009 work on "attention residue" showed that switching between tasks leaves part of your attention stuck on the previous one. Gloria Mark at UC Irvine measured the recovery cost: 25 minutes on average to fully return to an interrupted task. A writer scanning a toolbar for a formatting button is not just losing that fraction of a second — the cognitive switching cost compounds across a full day.
The best modern editors have converged on a three-layer menu pattern that minimizes visual noise:
- Keyboard shortcuts — zero visual footprint for experienced users
- Slash commands (
/) — visible only when invoked, then dismissed - Bubble menu on text selection — visible only when contextually relevant
This pattern replaces the permanently-visible toolbar with contextual controls that appear only when needed. The result is a writing surface that presents content, not chrome.
Documentation teams should treat visible UI complexity as a cost, not a feature. A toolbar with 40 buttons is not "powerful." It is 40 sources of visual competition with the content your writers are trying to produce. If you work with structured content — components, conditions, variables — the authoring model is already complex enough. Adding XML syntax on top only increases the cognitive burden. The editor's job is to reduce surface-level noise, not add to it.
How Production Editors Apply (or Ignore) the Research
The gap between what research recommends and what editors ship is wide. Here is how six widely-used editors perform against the evidence.
iA Writer: The Research-Aligned Benchmark
iA Writer is the closest any production editor comes to systematically applying readability research. Oliver Reichenstein, iA's founder, has written extensively about the reasoning behind each typographic decision.
The editor uses custom fonts — iA Writer Mono, Duo, and Quattro — built on IBM Plex and designed specifically for extended screen writing. Font size is deliberately large ("We went for the biggest minimal font size," Reichenstein writes) and is not user-adjustable, because iA considers the question settled by research. Line length is user-selectable at 64, 72, or 80 characters — all within or near the research-recommended range.
iA Writer's focus mode highlights the active sentence and dims surrounding text, reducing the amount of content competing for the writer's attention at any given moment. There is no toolbar. Formatting is handled through keyboard shortcuts or Markdown syntax.
The limitation: iA Writer is a personal writing tool, not a documentation system. It has no content reuse, no conditional content, no multi-channel publishing, and no collaboration features. You cannot run a documentation team on it. But its typography decisions are a reference implementation of the research.
Notion: Good Defaults, Wrong Font Size
Notion bundles Inter as NotionInter at 16px with a line-height of 1.5. The line height is research-optimal. The content width defaults to a narrow centered column that keeps line length in the right range. The interface uses a floating bubble menu on text selection and slash commands for block insertion — no permanent toolbar.
The problem is the font size. At 16px, Notion sits at the absolute minimum the research supports, well below the 18-to-21px range where comprehension measurably improves. For short-form content — meeting notes, project briefs, quick documentation — 16px is adequate. For sustained technical writing, it falls short. Notion also uses a 4px base spacing unit that keeps the interface tight but can make dense documentation feel cramped.
Linear: Typographic Craft in an Unexpected Place
Linear is a project management tool, not a writing tool, but its text rendering is worth studying. It uses Inter Variable with negative letter-spacing, which tightens characters just enough to create a distinctive density without hurting readability. The interface builds hierarchy through spacing and proportion rather than borders and backgrounds — what Linear's team calls "a calmer interface."
The deeper lesson from Linear is architectural. Its local-first design (IndexedDB sync engine, all reads and writes local) eliminates loading spinners and network latency. The text you type appears instantly. For writers, input latency is a form of cognitive friction that most tools treat as an acceptable tradeoff. Linear demonstrates that it is not inevitable.
Dropbox Paper: One CSS Property That Changed Everything
Dropbox Paper uses Atlas Grotesk at 16px with a line-height of 26px (a ratio of 1.625 — notably generous) and a text color of #1b2733, a warm off-black. These are solid, research-aware choices.
But the most instructive detail is a single CSS property: -webkit-font-smoothing: antialiased. This switches macOS from subpixel rendering to grayscale antialiasing, making text appear thinner and more refined. The visual difference is subtle but immediate — text looks intentional rather than default. Every TipTap or ProseMirror-based editor can achieve this same effect with one line of CSS, yet many do not.
Bear: Native Rendering Advantage
Bear uses Bear Sans, a customized version of Clarika, and offers granular typography controls: font family, size, line-height, line-width, and paragraph-spacing. This level of control is unusual and commendable.
Bear's deeper advantage is native Swift and AppKit rendering. Native text rendering on macOS and iOS produces crisper letterforms at every size than any web-based editor can match. This is a structural gap — web apps render text through the browser's layout engine, which adds overhead that native apps bypass. For a documentation team evaluating editors, this means Bear will always feel better at rendering text. The question is whether that rendering advantage outweighs the collaboration and publishing features that web-based tools offer.
Google Docs: The Anti-Pattern
Google Docs defaults to Arial at 11 points — a font designed for UI labels at a size designed for print. On a 1440px-wide screen, a Google Doc stretches text far beyond 100 characters per line, well past the point where comprehension measurably degrades. The permanently-visible toolbar presents dozens of formatting options that compete with the content for attention.
The page metaphor itself is a skeuomorphic holdover. The white rectangle with margins exists because physical paper had edges. On a screen, it adds visual noise (the gray "desk" surrounding the page), forces artificial page breaks, and provides no functional benefit. A documentation team writing for web and PDF delivery gains nothing from seeing simulated paper edges during authoring.
Google Docs remains the most widely-used collaborative editor. Its typography decisions influence what millions of people consider "normal." That is the problem — its defaults have normalized a writing surface that contradicts nearly every readability finding of the past three decades.
The Editor Readability Scorecard
Grading each editor against the four core research parameters, plus UI complexity:
| Editor | Font size | Line length | Line height | Text contrast | UI complexity | Overall |
|---|---|---|---|---|---|---|
| iA Writer | 18px+ | 64 to 80ch (configurable) | ~1.5x | Off-black | Minimal (no toolbar) | A |
| Bear | Configurable | Configurable | Configurable | Configurable | Minimal | A- |
| Dropbox Paper | 16px | ~65ch | 1.625x | #1b2733 (off-black) | Minimal (bubble menu) | B+ |
| Notion | 16px | ~65ch | 1.5x | Default black | Low (slash + bubble) | B |
| Linear | 14px (UI text) | ~70ch | 1.5x | Near-black | Minimal | B- |
| Google Docs | 11pt (~14.7px) | 80 to 120ch (page-width) | ~1.15x | #000 (pure black) | High (permanent toolbar) | D |
Two patterns emerge. The editors with the best readability scores (iA Writer, Bear) are personal writing tools — no content reuse, no conditional content, no team publishing. The editors built for teams (Notion, Google Docs) have worse typography defaults, as if collaboration features crowded out attention to the writing surface.
Documentation tools that offer structured authoring should not have to make this tradeoff. The research numbers are known. The CSS is straightforward. The question is whether a tool's team treated typography as a requirement or an afterthought.
How Topicary Applies This Research
Topicary's editor is built on TipTap and ProseMirror. Here is how we applied the research above.
Content max-width: 65ch. This places the writing area at the center of the research-recommended range (55 to 66 CPL), regardless of the user's screen width. The content area does not stretch on a wide monitor.
Line height: 1.5x. Directly at the optimal value identified by Rello, Pielot, and Marcos. Not 1.2x (too tight), not 1.8x (too loose).
Text color: off-black. Not #000000. The editor uses a dark gray that meets WCAG AAA standards while reducing the overstimulation of maximum contrast during sustained writing sessions.
Collapsible toolbar. The toolbar hides with one click, leaving formatting accessible through keyboard shortcuts, slash commands, and a bubble menu that appears on text selection — the same three-layer pattern used by iA Writer, Notion, and Dropbox Paper. When you want a clean writing surface, the chrome gets out of the way.
Caret-color theming. The text cursor uses a branded color rather than the browser default black. Combined with custom ::selection colors and -webkit-font-smoothing: antialiased, these are one-line CSS changes that shift the editor from "default browser textarea" to "someone made decisions here."
None of these show up on a feature comparison spreadsheet. But they determine how your team experiences component reuse, conditional content, and publishing — because every feature is used through the writing surface.
Frequently Asked Questions
What is the ideal line length for a content editor?
Research converges on 55 to 66 characters per line (Dyson and Haselgrove 2001, Bringhurst). In CSS: max-width: 65ch. The Baymard Institute found text wider than 80 CPL was skipped 41 percent more often than text in the 60 to 70 range.
Does font size affect writing quality?
Yes — through comprehension and fixation duration. Rello, Pielot, and Marcos (2016) measured significant improvement at 18 points and above. For writers who compose and proofread in the same session, the difference between 14px and 18px is functional, not cosmetic.
Is dark mode worse for proofreading?
Piepenbrock, Mayr, and Buchner (2013) found a clear positive polarity advantage: dark text on light backgrounds produced better proofreading accuracy. Halation — bright letterforms glowing into dark backgrounds — worsens this for the roughly 47 percent of people with some astigmatism. If you proofread in dark mode, use off-white on dark gray, not #FFF on #000.
Should documentation editors use serif or sans-serif fonts?
On modern screens, it matters less than x-height, letter spacing, weight, and contrast. Bernard and colleagues (2002) found no significant speed or comprehension difference between the two. For accessibility, sans-serif fonts with large x-heights perform better for low-vision users (meta-analysis of 18 studies, 1,500+ subjects, Journal of Visual Impairment and Blindness).
Can you fix bad editor typography with custom CSS?
Partially. You can override font size, line height, and content width with a user stylesheet. You cannot fix input latency, menu architecture, or the interaction between text rendering and the editor's framework. Typography is the visible layer, but it sits on architectural decisions — like whether the tool uses docs-as-code or a structured editor — that CSS cannot reach.