Responsive design: fundamentals that have not gone out of date

What is it and where does it come from?

Before 2010, many sites had a desktop version and a separate mobile one. Marcotte proposed a different idea: a single interface that responds to the space available. In the A List Apart article, published on 25 May 2010, the approach is described as “three technical ingredients”: fluid grids, flexible images and media queries.

Marcotte sums up media queries this way: they are, in short, “conditional comments for the rest of us”. They let you apply different styles depending on conditions in the browser, with the same HTML.

The term is now so common that it seems obvious, but the idea still demands design decisions. Adapting is not just shrinking: it means deciding what is shown, in what order and with what hierarchy at each size.

Why does it matter to a designer?

Because the screen is not a variable you control. One design can be viewed on a phone 360 pixels wide, on a 1440-pixel laptop or on a vertical monitor. Designing for a single size means designing for a minority of situations.

Responsive design also forces you to think about content. If a long title breaks the layout at a certain width, the problem is not the CSS: it is a design decision about how much text fits and how it is resolved.

What are the fundamentals?

According to web.dev, the practical fundamentals are these:

1. Viewport. A meta tag with width=device-width, initial-scale=1 tells mobile browsers to use the real screen width. Without it, according to web.dev, the page loads very zoomed out and the text is hard to read. web.dev also advises against maximum-scale and user-scalable in that tag, because they stop people from zooming.
2. Fluid grids. Measurements in percentages, fr units in CSS Grid or relative units, instead of fixed pixel widths.
3. Flexible images. web.dev recommends max-width: 100% on all images so they shrink to the available space, and keeping the width and height attributes so the browser reserves room before they load.
4. Modern layouts. Flexbox and CSS Grid allow many arrangements without media queries.
5. Media queries. Used where the layout really needs to change, not before.

MDN defines media queries as a way to apply CSS styles depending on the media type (for example, screen or print) or on features such as resolution, orientation or viewport width. For range features like width, you can use the min- and max- prefixes or the operator syntax: (width <= 1250px) is equivalent to (max-width: 1250px).

Mobile-first or desktop-first?

The debate is old and still current. web.dev recommends designing the content to fit a small screen first, and choosing the main breakpoints by starting small and expanding upward until a change is needed. This is the approach behind the note on mobile-first design.

The practical reason is that on a small screen every priority decision is more visible. If the content works at 360 pixels, larger screens only need extra space, not the removal of what was superfluous.

Which breakpoints should you use?

web.dev recommends not defining breakpoints by device class, brand or operating system. Devices change every year; content changes when the text stops fitting. So a good breakpoint is the width at which the layout breaks, not the width of a particular phone.

Two concepts help you decide. Container queries apply styles to an element based on attributes of its container, such as its size, rather than the viewport. You turn them on with container-type: inline-size on the container and query them with @container (width > 700px) { … }; MDN presents them as an alternative to media queries. That way a card adapts to the slot it sits in, whether that is a narrow column or the full page. The full comparison is in breakpoints versus container queries. And intrinsic sizing lets the browser decide sizes based on content, without fixing values in each case.

Example

Illustrative example: a product card with an image, name, price and button. On a small screen, the card takes the full width, the image is cropped to a fixed ratio and the button spans the whole width so it is easy to tap. Above a certain width, two cards sit side by side. On review, the team finds that the product name can run to three lines in a narrow card and push the price out of the visible area. The fix is not a new breakpoint: it is limiting the name to two lines and moving the price above the button.

For your next design: test the same component with its longest and shortest content, at two different widths. If something breaks, note the width at which it happens; that is the point where you need to decide on a change.

When should you NOT rely on it?

• When the piece does not need to adapt. A printable document or a fixed image with a controlled ratio does not need media queries, and forcing them adds maintenance cost.
• When adapting means hiding content. web.dev warns against hiding content just because it does not fit on the screen: screen size does not tell you what a person needs. Hiding important information on small screens puts it out of their reach.
• When you design four complete layouts instead of one that changes in parts. Maintaining four versions tends to produce errors.

Common mistakes

• Forgetting the viewport tag. Without it, adaptation does not work on mobile.
• Using fixed pixel widths for containers that should flow.
• Defining breakpoints by device brand instead of by content.
• Designing only for desktop and adapting afterwards.
• Hiding content on small screens without offering another way to reach it.
• Testing only two widths. Problems appear at the in-between widths.

Related in the wiki

For the difference between adapting by screen and adapting by component, read breakpoints versus container queries. For concrete scaling strategies, see responsive scaling strategies. And to understand when a fixed grid makes more sense than an intrinsic one, review layout grid versus intrinsic decisions.

Sources

• Responsive Web Design, Ethan Marcotte, A List Apart (25 May 2010)
• Responsive web design basics, web.dev (Pete LePage and Rachel Andrew)
• Using media queries, MDN Web Docs
• Container queries, MDN Web Docs