Breakpoints belong where content becomes hard to read, not at device widths

What it is

A breakpoint is the width at which layout rules switch, not a catalogue of phone / tablet / desktop products. 375, 768, and 1024 describe the shipping width of some year's device, not the width at which this content becomes hard to read. Line length past a comfortable measure, table columns crushed until labels will not fit, nav items overlapping or truncating — failure happens at particular pixels. Put the breakpoint just before those failures, so different modules can, and often must, have different values.

The question is where to cut, not whether container queries should replace the viewport, and not whether fewer breakpoints would let content flow. Device names are not a ruler.

Why it happens

Unreadability is content metrics hitting available width. Type size and line-height decide how many characters fit a line; past roughly 60–80 Latin characters (or the comparable Chinese measure), saccades start losing the next line. A data table's minimum column widths summed exceed the container, so cells wrap or overflow. Navigation is a set of items that cannot be dropped; when their widths sum past the container they overlap. Those thresholds come from font, copy, and column count, not from "is this an iPad". Pinning breakpoints to device widths assumes every module fails at the same pixel — the heading may still be generous while the table is already broken.

So the ruler is this content's failure point. Drag the viewport (or container) wide to narrow, note the width where each module drops from "readable, tappable, non-overlapping" to "starting to fail", and cut slightly on the still-good side. Modules cut independently; the page need not share a global 768. Device catalogues remain sampling points for tests, not sources of cut values.

Where it stops holding

A brand rule that "tablets go two-column" is a product decision, not a content threshold; once in code it is still an arbitrary width, and split-screen or enlarged text will cut in the wrong place. Measure taken on a desktop comp shifts after production fonts, another language, or large type; breakpoints must be remeasured. An image gallery cuts on minimum image edge, body copy on measure — they do not share a number. At extremely narrow widths unreadability may be unsolvable (another cut still will not fit); then the information structure has to change, not another breakpoint. Print, ebooks, and fixed canvases are not on this width axis.

Applying it

• Drag width separately on navigation, body, data tables, and card grids. Record the pixel where each becomes hard to read (overflow, overlap, overlong measure, colliding controls) and set the breakpoint slightly wider.
• Do not write 375 / 768 / 1024 or a device marketing name as the cut. Devices are samples for verification, not names of rules.
• Let modules use different cuts. Do not force a table and a heading to switch at one pixel for page-wide neatness.
• How to check: with production fonts and real copy, drag wide to narrow and screenshot both sides of each cut. The cut should sit between "still fine" and "starting to fail". If content is still comfortable, or has been broken for a long stretch already, it is not a content threshold.

Related

• Same group: R3.11.2 Layout switches must keep elements recognisably the same · R3.11.3 Landscape and split-screen are different width values of the same rules
• Nearby: R3.03 Responsive Implementation · J2.11 Text Zoom and Reflow · K1.02 Screen Size and Density
• Search terms: content-threshold breakpoint · device width · readable measure · breakpoint