HTML & CSS / Adaptable interfaces / Lesson 9
Responsive layout and media conditions
Adapt layouts to content and available space while preserving zoom, orientation, and input flexibility.
On this page
Lesson goals
- Define responsiveness as behavior
- Change a relationship at a content threshold
- Test transitions, not only endpoints
Define responsiveness as behavior
A responsive design preserves useful relationships as available space, content, and user settings change. It is not a desktop screenshot scaled down or a collection of fixed widths for named phone models. Begin with a narrow usable flow, then add columns or alignment when the content can support them. Device width is only one variable: a desktop window can be narrow, a phone can rotate, and zoom changes effective CSS-pixel space. Content length and language can expose failures at the same viewport. Define what must remain readable, reachable, and in a coherent order before choosing breakpoints.
Use fluid constraints before breakpoints
Percentages, relative units, maximum sizes, and flexible tracks solve many problems continuously. Breakpoints then change a relationship when a genuine threshold is crossed, such as a sidebar no longer fitting beside text. Do not disable pinch zoom or impose an artificial maximum user scale to hide overflow. A viewport declaration is necessary context for typical mobile layouts, not a replacement for flexible content. Use logical sizing and spacing so right-to-left layouts do not require rewriting every physical side. Test the minimum space your actual task needs rather than assuming all screens above one familiar width are equivalent.
Change a relationship at a content threshold
The first example presents an aside after the main article in source order. A media query places them in two columns only when the viewport is sufficiently wide for this teaching fixture. The content remains readable without the query. That is an enhancement to arrangement, not a second copy of the document hidden for another device. Duplicated desktop and mobile markup often drifts and can duplicate focusable controls or ids. Prefer one meaningful structure unless a real content requirement justifies otherwise. Check that the chosen visual arrangement still follows an understandable reading and keyboard sequence.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Content breakpoint</title>
<style>
.layout { display: grid; gap: 1rem; } @media (min-width: 45rem) { .layout { grid-template-columns: minmax(0, 2fr) minmax(0, 1fr); } }
</style>
</head>
<body>
<main><h1>Workshop guide</h1><div class="layout"><article><h2>Preparation</h2><p>Read the notes before joining the session.</p></article><aside><h2>Materials</h2><p>A text editor is sufficient.</p></aside></div></main>
</body>
</html>
One column when narrow; two proportional columns when wide.One column is the default. The wider query adds a proportional secondary column without duplicating content.
Respect capabilities and preferences
Media queries can express preferences and interaction capabilities as well as width. prefers-reduced-motion offers a way to reduce nonessential movement, and hover or pointer features can inform supplementary affordances. A device can have multiple inputs, so do not equate a narrow viewport with touch-only use or a wide viewport with mouse-only use. The second example adds a hover decoration only where hovering is available, while keeping focus styling independent. The base link remains usable in every case. A hover-only tooltip containing essential instructions would still be an inaccessible design even if its media query is technically correct.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Capability enhancement</title>
<style>
a { text-decoration: underline; } a:focus-visible { outline: 3px solid #174e9a; outline-offset: 3px; } @media (hover: hover) { a:hover { text-decoration-thickness: .2em; } }
</style>
</head>
<body>
<main><h1>Interaction states</h1><a href="#notes">Read the notes</a><section id="notes"><h2>Notes</h2><p>Focus remains visible without hover.</p></section></main>
</body>
</html>
A usable link with separate hover and focus treatments.Hover adds decoration only. Keyboard focus has its own visible treatment and the link is never hidden behind a capability assumption.
Test transitions, not only endpoints
Resize through the space around every breakpoint, not just one phone and one desktop screenshot. Test longer headings, translated labels, browser zoom, orientation, and software keyboard effects where relevant. Inspect horizontal overflow by locating the first oversized box rather than clipping the whole document. A sticky or fixed element can cover focused content when the viewport becomes short, so verify vertical space too. Record the settings used and the relationship that failed. A small matrix of meaningful conditions gives stronger evidence than a large collection of screenshots all using the same short content and default font.
Common errors and fixes
The mobile layout is a shrunken desktop canvas
- Why it happens
- Fixed minimum widths define the entire page.
- How to fix it
- Use fluid constraints and content-driven layout changes.
- Prevent it next time
- Test the narrow base before adding columns.
Keyboard users cannot discover a hover-only instruction
- Why it happens
- The design assumed one input method.
- How to fix it
- Keep essential instructions persistently available.
- Prevent it next time
- Test focus and touch separately from hover.
Two responsive copies create duplicate ids
- Why it happens
- Separate mobile and desktop trees repeat the same controls.
- How to fix it
- Prefer one structure with adaptable layout.
- Prevent it next time
- Inspect hidden as well as visible markup.
Check your understanding
1. Choose a breakpoint for a sidebar without using a device brand.
Show worked solution
Start with one column, then widen the viewport until both the article’s readable line length and the sidebar’s content fit comfortably with their gap. Place the transition near that content threshold and test neighboring widths, translated content, and zoom rather than assuming one pixel value proves responsiveness.
2. Why can an interface pass a wide-screen check but fail at 200% zoom?
Show worked solution
Zoom reduces the effective layout space and enlarges content, exposing fixed widths, clipped text, or controls covered by fixed elements. Repeat the actual task after zooming, inspect the failing box, and repair its constraints instead of restricting the user’s zoom capability.
Key takeaways
- Responsive behavior follows content and available space.
- Input capabilities are not device-width labels.
- Test the widths around every transition.