Dom-Free Text Height Estimation In The Browser

Issue 88 Edition 2026-03-29 6 min read

General

Sources: 1 • Confidence: Medium • Updated: 2026-04-12 10:21

Key takeaways

Pretext can calculate the height of line-wrapped paragraph text without rendering it in the DOM.
Pretext's prepare() tokenizes text into segments (including soft hyphens, non-Latin sequences, and emoji), measures segments using an off-screen canvas, and caches results.
Cheng Lou has stated that Pretext's behavior was iteratively refined over weeks using Claude Code and Codex with browser ground truth at significant container widths.
Pretext is described as achieving much faster text measurement than DOM render-and-measure by using multiple optimization tricks.
Pretext testing compared estimates to browser ground truth by rendering the full text of The Great Gatsby across multiple browsers, and later expanded to public-domain corpora in multiple languages including Thai, Chinese, Korean, Japanese, Arabic.

Pretext can calculate the height of line-wrapped paragraph text without rendering it in the DOM.
Pretext's prepare() tokenizes text into segments (including soft hyphens, non-Latin sequences, and emoji), measures segments using an off-screen canvas, and caches results.
Pretext's layout() emulates browser word-wrapping to compute wrapped line count at a given width and derive resulting height.

Pretext's prepare() tokenizes text into segments (including soft hyphens, non-Latin sequences, and emoji), measures segments using an off-screen canvas, and caches results.
Pretext's layout() emulates browser word-wrapping to compute wrapped line count at a given width and derive resulting height.
Pretext splits computation into a single prepare() step followed by multiple layout() calls.

Cheng Lou has stated that Pretext's behavior was iteratively refined over weeks using Claude Code and Codex with browser ground truth at significant container widths.
An interactive artifact was built with Claude to visualize a simplified version of Pretext to aid understanding.

Pretext is described as achieving much faster text measurement than DOM render-and-measure by using multiple optimization tricks.
Cheng Lou has stated that the Pretext engine is only a few kilobytes, accounts for browser quirks, and supports complex multilingual scenarios including mixed Korean and right-to-left Arabic and platform-specific emojis.

Pretext testing compared estimates to browser ground truth by rendering the full text of The Great Gatsby across multiple browsers, and later expanded to public-domain corpora in multiple languages including Thai, Chinese, Korean, Japanese, Arabic.

What is the measured accuracy of estimated heights versus DOM ground truth across browsers, fonts, and scripts (including worst-case and tail errors)?
What are the actual performance characteristics (throughput/latency) compared to DOM measurement under defined workloads, including cold-cache vs warm-cache and low-end devices?
What is the verified production bundle size of Pretext (after typical bundler/minifier settings), and what optional features or language support affect that size?
How does Pretext handle font loading and late style changes (e.g., font substitution, variable fonts), and what cache invalidation mechanisms exist?
Which specific browser versions/engines are covered by the ground-truth tests, and how often are tests rerun or updated to track engine changes?

If Pretext reliably estimates wrapped text height without DOM measurement, teams building web editors, virtualization, and responsive layout tools may reduce layout thrash and improve interaction latency, creating demand for tooling or services around algorithmic text layout.
The prepare then layout split plus caching suggests a reusable measurement layer. If it generalizes across widths and texts, it could become a foundational library inside UI frameworks or design systems where repeated layout queries are common.

Published benchmarks showing throughput and latency versus DOM render and measure under defined workloads, including cold cache versus warm cache and results on low end devices.
Reported accuracy distribution versus browser ground truth across multiple browsers, fonts, and scripts, including worst case and tail errors, plus a clear error budget acceptable for production use.
Verified production bundle size after typical bundling and minification, with a clear breakdown of optional language features and a documented strategy for font loading and cache invalidation.

Material height estimation errors versus browser ground truth that persist in certain fonts or scripts, especially large tail errors that break pagination, virtualization, or editor cursor positioning.
Real world performance fails to beat DOM measurement once font loading, style changes, and cache invalidation are included, or gains disappear on common mobile devices.
Ongoing maintenance burden where browser engine changes frequently break matching behavior and tests are not rerun or updated across engines and versions.