Breakpoints

Let the content decide

Widen a browser window slowly and watch your own page. The width at which a line of text becomes uncomfortably long, or a three-column grid becomes cramped, is a breakpoint.

That method produces breakpoints specific to your design, which is the point. A layout with wide cards needs to rearrange earlier than one with narrow ones, and no device list knows that.

It is also stable. Device sizes change every year and content does not, so breakpoints chosen this way keep working long after a list of popular phone widths is out of date.

Write the widths down once you find them. A breakpoint discovered by dragging a window and never recorded is one the next person re-derives differently, and the layout slowly acquires four where it needed two.

Why device-based breakpoints fail

There are too many devices and they change constantly. A set of breakpoints matched to this year's popular phones and tablets is a maintenance commitment with no end.

It also misses the cases in between. Somebody with a browser window at an unusual width, a split screen, or a large phone in landscape falls between the chosen sizes and gets a layout designed for neither.

Designing for the content rather than the device covers all of those automatically, because the layout responds to the space it actually has.

How many you need

Two or three for most small business sites. One where a single column becomes two, one where two become three, and occasionally one to constrain the text column on very wide screens.

More than that usually indicates a layout fighting itself. Each additional breakpoint is another arrangement to check and another place for something to break unnoticed.

Start with none. Build the page so it works in a single narrow column, then add a breakpoint only where the extra space genuinely allows something better.

Count what you already have before adding another. Sites that grew over a few years frequently carry breakpoints nobody remembers adding, each one another arrangement that has to keep working.

What to check at each one

The list below is what to look at every time a layout changes. Most breakpoint faults are found in seconds by dragging a window slowly rather than jumping between fixed sizes.

• Text never runs to the edge
• Line length stays comfortable
• Nothing overlaps or overflows
• Images keep their proportions
• Tables remain usable or scroll within themselves
• The main action stays visible
• Nothing important disappears

Narrow first is easier

Designing the narrow layout first and adding to it is consistently easier than designing wide and removing. A narrow layout forces the priority decisions early, which is where they belong.

It also matches where most visitors are. Our page on mobile layout covers the phone case, and building outward from it means the majority experience is the one designed rather than derived.

The wide layout then becomes an enhancement: more room, so two columns instead of one, rather than a full layout being squeezed down until it fits.

Test between the breakpoints

Faults hide in the widths nobody checked, though none of it reaches an answer engine, which reads the markup rather than the layout. Dragging the window slowly from narrow to wide surfaces overlaps and awkward gaps that jumping between three fixed sizes never reveals.

Pay particular attention just before and just after each breakpoint. Those are the widths where a layout is most stretched, and where a long word or a large image causes an overflow.

Our page on responsive design covers the wider approach. Breakpoints are one mechanism inside it rather than the whole of it.

Zoom counts as a narrow screen

A reader zooming in on a desktop is effectively narrowing the viewport, so the mobile layout is what they get. A site that handles narrow widths badly also handles zoom badly.

That connects breakpoints to accessibility rather than convenience. Our page on text resizing covers what somebody relying on zoom actually experiences.

Test by zooming your own site to double size in a desktop browser. Anything that overlaps or disappears there is a fault for a real group of readers, not an edge case.