Field method
Record a browser observation you can repeat
A useful result includes the conditions that produced it. Keep the settings, define the measurement, and preserve the uncertainty.
Give the observation a small job
“The layout is broken” is hard to reproduce because it leaves the reader to guess what happened. “This sentence extends beyond its box when wrapping is disabled” identifies an object, a condition, and a visible outcome. Begin with a question that one controlled change could help answer.
Write your prediction before moving a control. Perhaps a narrower box will gain another line. Keep that prediction separate from the result you actually see. A run that stays unchanged can be useful too: it may show that your starting point was nowhere near a wrapping boundary.
Preserve the inputs and the environment
Save the exact text, including spaces and line breaks, along with width, font size, and wrapping mode. Use the lab's settings export for the values it records. Add the date, browser name and version, operating system, and zoom setting to your own note. Record the displayed preview width if the page has constrained it.
Keep units explicit. CSS pixels are the units used for the layout values discussed here; a screenshot's image pixels are a different record. MDN explains that devicePixelRatio relates physical display pixels to CSS pixels and is affected by page zoom. A device name alone is not enough context for comparing two captures.
Sources: MDN: Window.devicePixelRatio
Know what the number means
An element's getBoundingClientRect() reports a rectangle around the rendered element, including padding and borders. Its position is relative to the viewport. A reported block width therefore does not tell you the width of the printed letters or the number of text lines. Preserve the measurement's name instead of renaming every value “text width.”
For an appropriate element, clientWidth describes its inner width, including padding but excluding borders and a vertical scrollbar. scrollWidth includes content beyond the visible area. Comparing those two values can reveal horizontal overflow in the measured element. It cannot prove that every word is readable: inspect clipping, overlap, and the surrounding interface as well.
Sources: MDN: Element.getBoundingClientRect(), MDN: Element.clientWidth, MDN: Element.scrollWidth
Wait for the state you mean to observe
A measurement taken while a web font is loading may describe a temporary rendering. In scripted work, document.fonts.ready provides a point after loading and layout work for the fonts used by the document has completed. This does not guarantee that every declared font was used; optional fonts can miss their loading window.
For a manual run, let the page settle and record anything unusual, such as a visible font change. Repeat the baseline before comparing variants. If repeated runs disagree, preserve both results and investigate the changing condition. A second value is evidence to explain, not an inconvenience to average away.
Sources: MDN: Document.fonts
Make the comparison inspectable
Change one input, repeat the observation, and save a separate record. Use descriptive filenames such as “normal-wrap-narrow” and “no-wrap-narrow,” with a date or sequence number. Keep the exported settings beside a screenshot and a short written observation. The screenshot shows what you noticed; the settings make it easier to attempt the same run.
When you share the result, distinguish what you measured, what you inferred, and what remains untested. Another browser can be a useful next comparison, but its result belongs to that environment. A compact, honest note is more reusable than a confident claim that quietly depends on one machine, one font, and one moment.
Distinguish the sample from its viewing window
On September 12, 2026, we measured the same Text Layout Lab sample across three viewport runs in Chrome desktop. The text was “Read the full label before continuing.” Box width stayed at 300 CSS pixels, text size at 20, and wrapping at normal. The lab uses Arial, Helvetica, sans-serif, a 1.5 line height, 12-pixel padding and a 1-pixel border. Zoom was unchanged during the run.
The first 1280-pixel viewport produced a 300-by-86-pixel sample. Its client width and scroll width were both 298. At a 390-pixel viewport, all four sample measurements stayed the same, while the surrounding preview area’s client width became 296 and its scroll width reached 344. Restoring the 1280-pixel viewport returned that area to 512 for both widths. The table uses CSS pixels throughout.
The lab displayed “No” horizontal overflow in every run because it measures the sample element. The narrower preview area still had more scrollable content than visible width. These readings describe different elements. They demonstrate why a sample-level result cannot establish that the surrounding interface fits. The dated measurement record preserves settings and both sets of dimensions.
To repeat the comparison, use the same sample and controls, change only viewport width, and record the actual CSS viewport width. Save both a baseline and its repeat. If the repeat differs, investigate the changed condition before attributing the difference to width. The exact Chrome version and zoom level were not recorded, limiting exact reproduction. No screenshots or second-browser measurements accompany this run; a narrow desktop viewport does not establish mobile-device behavior, browser-zoom behavior or accessibility conformance.
Continue with Open Text Layout Lab, then Read the September 12 measurement record.
| Run / viewport width | Sample box width × height | Sample client / scroll width | Preview client / scroll width |
|---|---|---|---|
| 1280px baseline | 300 × 86 | 298 / 298 | 512 / 512 |
| 390px narrow viewport | 300 × 86 | 298 / 298 | 296 / 344 |
| 1280px repeated baseline | 300 × 86 | 298 / 298 | 512 / 512 |