Session 6: Responsive Design

Without `<meta name="viewport" content="width=device-width, initial-scale=1">` a phone does not use its real width. It assumes the page was built for a desktop, renders it at around 980 pixels wide, and shrinks the whole thing to fit — which is why an old website appears tiny on a phone and requires pinch-zooming to read. That tag tells the browser to use the device's actual width, and it is the precondition for every other responsive technique. Missing it means your media queries never fire, because the browser believes it is 980 pixels wide.

Understand also that a phone's CSS pixel width is not its physical pixel count. A phone with a 1080-pixel-wide screen typically reports about 360 to 412 CSS pixels, because of its pixel density. This is why you design against widths like 360, 390 and 412 rather than 1080, and why testing in the dev tools device toolbar — which reports CSS pixels — is meaningful. The common working widths to test are roughly 360 (small Android), 390 (iPhone), 412 (large Android), 768 (tablet) and 1280 and up (desktop).

The Nigerian context sharpens this: the overwhelming majority of visitors arrive on a phone, often on mobile data, often on a mid-range Android at the narrower end of that range. A site designed for a desktop first and adapted afterwards will fail precisely where the customers are. This is why mobile-first is the correct method here rather than a preference.

A media query applies CSS only when a condition holds. `@media (min-width: 768px) { ... }` means 'when the viewport is at least 768 CSS pixels wide'. Inside it you override the base styles, and because it comes later in the file it wins ties by source order — which is exactly how the mobile-first method works.

The question beginners get wrong is where to put the breakpoints. The answer is not at the widths of popular devices, because devices change every year. It is at the widths where your content breaks. Widen the browser slowly and watch: at some point a line of text becomes too long to read comfortably, or a row of cards becomes too cramped, or a column becomes too wide. Those are your breakpoints. In practice that produces three or four — around 600, 768 and 1024 — and they hold across device generations because they come from the content rather than from a product list.

Keep the number small. Every breakpoint is a set of rules you must maintain and test, and a stylesheet with twelve breakpoints is a stylesheet nobody can reason about. Three or four, chosen from content, covers essentially every business site you will build.

The best responsive technique is the one that needs no media query. Percentages and the `fr` unit make things share available space automatically. `max-width: 100%` on an image stops it overflowing its container, which is the single most important line for preventing horizontal scroll on a phone. The Grid pattern `repeat(auto-fit, minmax(260px, 1fr))` reflows a card grid with no query at all. And `clamp()` — `font-size: clamp(1.75rem, 4vw, 3rem)` — gives a heading that scales fluidly between a minimum and a maximum, which produces genuinely smooth type scaling rather than three abrupt jumps.

`vw` is a viewport width unit — 1vw is one percent of the viewport width — and it is powerful but must always be bounded. A font sized purely in `vw` becomes unreadably small on a phone and absurdly large on a wide monitor, which is why `clamp()` with a `rem` floor and ceiling is the right pattern rather than `vw` alone.

Reach for fluid units before reaching for a media query, every time. A layout built from flexible tracks and clamped type often needs only one or two queries for genuinely structural changes, which makes it smaller, faster and far easier to maintain.

A four-megabyte hero photograph served to a phone on mobile data is a lost visitor, and it is one of the most common performance failures on Nigerian business sites. Three techniques, in order of importance. First, always set `img { max-width: 100%; height: auto }` so no image can overflow its container — without it, one large image creates a horizontally scrolling page, which is an immediate usability failure.

Second, compress and resize before uploading. Resize to the largest size you will display — usually no more than about 1600 pixels wide for a full-width hero — and compress; the visual difference is nil and the file size difference is often tenfold. This one habit matters more than any markup cleverness.

Third, where a genuinely large image must be served responsively, use `srcset`, which offers the browser several sizes and lets it choose based on the screen: `srcset="hero-600.jpg 600w, hero-1200.jpg 1200w"` with a `sizes` attribute describing the displayed width. The browser picks the smallest sufficient file. This is worth doing for a hero image on a content-heavy site, but it is not a substitute for compressing in the first place.

Mobile first means writing the base CSS for the narrowest screen, then adding media queries with `min-width` to enhance for larger ones. The opposite — desktop first with `max-width` queries removing things — produces a stylesheet full of overrides and cancellations, and it means the phone version is an afterthought built by subtraction. Mobile first also has a performance benefit: the phone, which has the least capable connection and processor, downloads only the base CSS rather than a desktop stylesheet it then partially undoes.

The practical workflow is: build and test at 360 pixels wide first, get everything working and readable there, then widen and add enhancements at the content-driven breakpoints. If a layout works at 360 it almost always works wider; the reverse is not true.

Then test properly, and this means a real phone, not only the dev tools device toolbar. The toolbar is excellent for fast iteration but it does not tell you how the page performs on mobile data, how a touch target feels under a thumb, or whether text is legible in daylight. Test the real thing: load the page on a phone over mobile data, time it, try every link and the form, and read the body text without squinting. Touch targets should be at least about 44×44 CSS pixels — a link that is fine with a mouse is impossible to tap accurately — and they need space between them, because a fat-fingered tap on the wrong link is a real and common frustration.