Responsive foundations

Responsive design is not “make it work on an iPhone”. A page has to survive a long German translation, a browser zoomed to 200%, a split-screen window on a tablet, a user who set their default font to 24px, and content you haven’t seen yet. Phone widths are one small part of that.

The good news is that most of the work happens before you write a single media query. You do it by choosing flexible values instead of fixed ones.

Two rules that do most of the work

Images that never overflow their container, and a page column that follows the window until it reaches a readable width:

img {
  max-width: 100%;
  height: auto;
}

.page {
  width: min(100% - 2rem, 70rem);
  margin-inline: auto;
}

The image shrinks with its container and keeps its proportions because height: auto recalculates the height. The page column takes the full width minus a 1rem gutter on each side, until 70rem, where it stops growing and centers. Neither rule knows or cares what device it’s on.

Let CSS do the math

Before you add a breakpoint, ask whether normal flow, wrapping, min(), max(), clamp(), Flexbox, or Grid can solve the problem on their own. Very often they can. The card grid we built has no breakpoint and works from 320px to 4K.

A few habits that keep layouts flexible:

• prefer max-width to width for containers
• prefer a flex basis or a minmax() track to a fixed column width
• never put a fixed height around text, it will clip when the text grows
• use rem for sizes that should follow the user’s font preference

Don’t fight the user

Never disable zoom in the viewport meta tag. Never assume the viewport is a fixed size. People zoom because they need to, and a layout that breaks at 200% is a layout that excludes them.

Testing is where this gets real. Resize the window slowly. Zoom to 200% and then 400%. Set the browser’s default font size to 24px. Replace “Learn more” with the longest label you can imagine. If the page still works, you built it right.

Input is part of responsive too

A finger needs bigger targets than a mouse pointer. A keyboard needs visible focus and a sensible Tab order. Someone might use a touchscreen laptop with a trackpad, so don’t assume one input from a screen size. Responsive design covers what the user can do, not only how wide their window is.

Try this on the course page: use the responsive mode in DevTools as a starting point, then close it and resize the real browser window. Zoom to 200%. The device presets in DevTools are examples. The web has no boundaries between them.