Responsive Design and Media Queries: Mobile-First Breakpoints, Relative Units, and the Viewport Meta Tag

Responsive design means building one HTML document that reshapes itself to fit any screen, and it rests on three pieces working together: the viewport meta tag, relative units, and media queries. Mobile-first is the strategy that ties them together — you write your base CSS for the narrowest screen, then use min-width media queries to add columns and spacing only once there is room for them.

The viewport meta tag comes first

Mobile browsers render pages into a virtual viewport that is wider than the screen — commonly around 980 CSS pixels — and then scale the whole result down to fit. Your breakpoints never fire, because as far as the browser is concerned the viewport really is 980px wide. One tag in the <head> fixes it:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width sets the layout viewport to the device's own width in CSS pixels instead of that wide default, and initial-scale=1 loads the page at 100% zoom. Steer clear of user-scalable=no or a restrictive maximum-scale: blocking pinch-zoom shuts out readers with low vision, and WCAG expects at least 2× scaling. Browsers increasingly override those values anyway — iOS has ignored user-scalable=no by default since iOS 10 — so writing them buys you nothing but a bad signal.

Relative units keep sizes flexible

A font size in px is fixed: it ignores the reader who has raised the default text size in their browser settings. (Browser zoom still scales pixels; the default-font-size preference does not.) Relative units respond to both. The ones you will reach for constantly:

• em — resolves against the element's own computed font-size, except when you are setting font-size itself, where it resolves against the inherited font size.
• rem — resolves against the root element's font size (the html element), so it never compounds through nesting.
• % — resolves against the containing block, but which dimension depends on the property. For padding and margin it is always the containing block's inline size — its width in a horizontal writing mode — even on the top and bottom sides.
• vw / vh — 1% of the viewport's width / height.
• ch — the advance measure of the "0" glyph in the current font, useful for capping line length with something like max-width: 65ch.

Writing mobile-first breakpoints

Base styles carry the single-column layout, and each min-width query layers on top of it:

.wrapper { display: grid; gap: 1rem; }          /* one column */

@media (min-width: 40em) {
  .wrapper { grid-template-columns: 1fr 1fr; }   /* two columns */
}

Pick breakpoints where your content starts to look wrong, not at the pixel width of any particular phone. And note that the width media feature describes the viewport, not the device's screen — the old device-width feature that did test the screen is deprecated.

Fluid layouts need fewer breakpoints than you think

Media queries are a tool, not a requirement. img { max-width: 100%; height: auto; } keeps images inside their container. grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)) reflows on its own. font-size: clamp(1.5rem, 4vw, 3rem) scales type between a floor and a ceiling with no query at all. Reach for a breakpoint only when fluid CSS cannot express the change. For the full topic map, see the WGU D276 Web Development Foundations study guide.

A worked example: why breakpoint order matters

Media queries feel like conditionals, so people assume the "best match" wins. It does not. A media query is a conditional group rule: it gates whether a rule is in play, and contributes nothing to specificity. When two gated rules with identical selectors are both open, the cascade falls through to source order.

/* Correct mobile-first order: small to large */
.card { padding: 1rem; }
@media (min-width: 40em) { .card { padding: 2rem; } }
@media (min-width: 60em) { .card { padding: 3rem; } }

At 1200px both queries match, but the 60em block comes last, so you get 3rem. Flip those two blocks and the 60em breakpoint silently stops working — no error, no warning, just a layout that refuses to grow past its medium size. If you write desktop-first with max-width, the rule reverses: order those blocks largest to smallest.

Mistakes people actually make

• Omitting the viewport meta tag. Every breakpoint you wrote is dead on phones, and the whole page renders zoomed out. This is the single most common reason a "responsive" page is not.
• Setting html { font-size: 62.5% } and expecting media queries to follow. They will not. Inside a media query, em resolves against the initial font size — the user agent or user preference — so your root declaration has no effect there. Your rem sizes shrink; your breakpoints do not move.
• Using 100vw for a full-width block. Viewport units are relative to the viewport including the space taken by a classic scrollbar, so width: 100vw on a vertically scrolling page overflows by the scrollbar's width and produces a horizontal scrollbar. Use width: 100% on a block-level element instead. (Switching to dvw does not help — the dynamic viewport units address the collapsing mobile toolbar, not the scrollbar.)
• Chaining em sizes. Nested elements each multiply the last, so 0.9em three levels deep lands at about 0.73 of the original. Use rem when you want a stable size and em when you genuinely want to scale with the local text.
• Picking breakpoints from a device list. Screen sizes change every year; your content's comfortable line length does not. Widen the browser until the layout looks awkward — that is your breakpoint.

Reasoning through the tricky cases

When a percentage confuses you, ask what its reference is, because it varies by property: padding and margin reference the containing block's inline size — its width in a horizontal writing mode — even on the top and bottom sides, while height: 50% references the containing block's height. When a fluid value confuses you, expand clamp(a, b, c) into max(a, min(b, c)) and evaluate it literally with real numbers.

Before reaching for a query at all, ask whether flex-wrap, minmax() with auto-fit, or clamp() already handles it — the fewer breakpoints you own, the fewer you can break. Ready to test yourself further? Work through the D276 practice questions.