Responsive design moved into the component

What changed in responsive web design since media queries?

Responsive web design used to mean one thing: ask the viewport how wide it is, then lay the page out to suit. That assumption is now the limitation. Container queries let an element read the width of the box it has been placed in rather than the width of the browser window, so a single component can be correct in a sidebar, inside a three-column grid and at full bleed without a variant class for each.

The capability is not experimental any more. Size container queries sit at 94.05 percent of global browser usage.¹ Support is no longer the deciding factor. Adoption is: 41 percent of State of CSS survey respondents had used size container queries at least once, and only 7 percent had used style queries, against awareness that rose from 81 percent to 86 percent.² Most production codebases are still solving a component problem with a page-level tool.

Two other shifts landed alongside. Fluid typography using clamp() replaced the stepped type scale, so text sizes move continuously instead of jumping at arbitrary widths. And intrinsic layout, mainly grid with auto-fit and minmax, absorbed a large share of the cases that used to need a breakpoint at all.

What are container queries, and how do they differ from media queries?

A container query applies styles based on the size of an element’s nearest registered ancestor container. A media query asks about the browser window. That is the entire difference, and it decides which one you should reach for.

Two declarations are involved. A parent opts in, and the child queries it.

.card-slot { container: card / inline-size; }

.card { display: grid; gap: 1rem; }

@container card (min-width: 28rem) {
  .card { grid-template-columns: 9rem 1fr; align-items: start; }
}

Note inline-size rather than size. Querying inline size measures width only and leaves height to content, which sidesteps the circular layout problem that makes full size containment awkward in normal document flow. Naming the container is optional and worth the discipline anyway, because an unnamed query resolves to the nearest container ancestor, and that ancestor changes the moment someone nests your component inside another one.

Container query units come with the feature. 1cqi is one percent of the container’s inline size, so padding, gaps and type can scale against the component’s own box rather than the page: padding: clamp(1rem, 4cqi, 2rem).

The failure mode this fixes is specific. A media query cannot distinguish a card that is narrow because the phone is narrow from a card that is narrow because it was dropped into a sidebar on a wide desktop. Both need the stacked layout. Only one of them gets it.

A component that has to be told where it is has not been designed. It has been configured.

One gotcha to plan for: declaring container-type applies layout containment, which makes that element a containing block for absolutely and fixed positioned descendants and creates a new stacking context. Sticky headers and dropdown menus that escape their parent will behave differently once you register the container around them. And an element cannot query itself, only an ancestor, so the container has to be the slot rather than the component.

Do container queries replace media queries?

No, and treating them as competitors misapplies both. The split that holds up in practice is by the decision being made, not by preference.

A rule that survives contact with a real codebase: if the answer to “how wide is this?” would change when someone moves the component to another part of the page, it is a container query. If the answer only changes when the user resizes the window, it is a media query.

How should fluid typography be set with clamp()?

clamp() takes a minimum, a preferred value and a maximum. The preferred value should mix a rem base with a viewport or container unit, so the type stays continuous without breaking browser zoom.

h2 { font-size: clamp(1.5rem, 1.1rem + 1.8vw, 2.5rem); }
p  { font-size: clamp(1rem, 0.98rem + 0.15vw, 1.125rem); }

Note the two very different curves. This is where most type scales go wrong. A single global clamp curve applied across the whole scale makes headlines feel right and body copy feel wrong at the same viewport, because headings want a wide range and body text wants almost none. Body copy should shift by a couple of pixels across the entire width range. A display heading can shift by twenty. Scope the curve per role, not per stylesheet.

Two constraints belong in the system rather than in a developer’s head. Never use a bare viewport unit as the preferred term, because a font size expressed purely in vw ignores browser zoom, and that is an accessibility failure rather than a style choice. And cap the measure as well as the size: setting max-inline-size in ch units on text containers does more for readability than any amount of clamp tuning.

Is mobile first design still the right default?

Yes, for two independent reasons, and the second one holds even if the first stops being true.

The traffic reason is straightforward. Mobile devices account for 58.5 percent of global website traffic,³ and a separate roundup puts mobile screens at close to 60 percent of page views worldwide.⁴ The narrow case is the majority case.

The authoring reason matters more and is unchanged by container queries. Mobile first means the base stylesheet describes the smallest, simplest layout, and every query adds to it. That keeps the base lean and lets container queries and media queries layer complexity on progressively. A desktop-first base does the reverse: it ships a heavy stylesheet that every narrow context then has to override, which means more CSS, more specificity fights and more opportunities for a component to inherit a layout it never asked for.

Mobile first also gives container queries a free fallback. Browsers without support ignore an @container block entirely rather than erroring, so an unsupported browser lands on the base narrow layout, which is a usable page rather than a broken one. Where a wider layout genuinely matters, wrap the alternative in @supports not (container-type: inline-size).

How do component breakpoints change a design system?

They change the unit of design. A page breakpoint system asks what a screen looks like at the tablet breakpoint. A component breakpoint system asks what a card does across its own width range, and above where it stops fitting. The second question is the one a design system can actually answer, because a component never knows what page it is on.

Three consequences for teams running a system across design and code:

• Name Figma variants for width ranges of the component, not for device classes. A variant called “Card / narrow” survives a redesign. “Card / mobile” does not, because it encodes an assumption that the component cannot verify.
• Express spacing and type tokens inside a component in container units where the value should track the component. That removes a whole category of variant: one definition covers three slots.
• Document a supported width range per component. Without it, a component is only ever tested at the widths it happened to be used at, and every new placement is a fresh bet.

The payback shows up in delivery rather than in aesthetics. Teams doing serious web development against a shared component library lose a meaningful share of review time to layout regressions caused by components being reused in contexts they were never sized for. Component-level breakpoints remove that category of defect rather than catching it later. The same logic holds when a system spans web and a native mobile app, where the component, not the screen, is the only stable unit across both.

What does responsive web design do for rankings and Core Web Vitals?

Google does not rank a page for being responsive. It indexes the mobile version of the page, and responsive design is the configuration Google recommends under mobile-first indexing, because one URL and one HTML payload serve every device.⁸ The benefit is the absence of failure: no content missing from the mobile HTML, no blocked resources, no structured data that exists on one device version and not the other.

Everything else runs through user behaviour and Core Web Vitals rather than through a responsiveness signal.

Read those bars as three separate measurements, because that is what they are. Industry aggregations put responsive sites at roughly 11 percent higher conversion rates than non-responsive ones,⁶ and non-optimised mobile sites at an average 60 percent bounce rate.⁷ Both come from vendor aggregation rather than controlled study, so treat them as direction rather than a forecast for your own site. The traffic share is the number to plan against.

The Core Web Vitals link is mechanical. Cumulative Layout Shift is mostly images and embeds without reserved dimensions, which responsive image handling fixes directly. Largest Contentful Paint on mobile is usually a hero image sized for desktop and delivered to a phone. Neither is a CSS layout problem, which is why a site can be fully responsive and still fail the vitals assessment.

What belongs on a responsive web design checklist?

1. Write the base stylesheet as the narrowest layout, with no width queries in it at all. Everything after that is an addition, never an override.
2. Register containers on layout slots, not on components. The slot declares container-type; the component queries it by name.
3. Use inline size containment unless you have a real reason to constrain height, and expect a containing block and a stacking context wherever you register one.
4. Reserve media queries for page chrome, the page grid, and non-size conditions such as reduced motion, colour scheme and print.
5. Give every clamp() curve a role. Body copy barely moves, display type moves a lot, and no curve uses a bare viewport unit as its preferred value.
6. Try grid auto-fit with minmax before writing any query. A large share of column-count breakpoints are not needed once the grid can size itself.
7. Set width and height attributes on every image so nothing shifts while it loads, and identify the mobile Largest Contentful Paint element specifically rather than assuming it matches desktop.
8. Test each component at its declared minimum and maximum width in isolation, not only inside the page it was built for.
9. Confirm the mobile HTML contains everything the desktop HTML contains, structured data included.

None of this is a rewrite of how responsive web design works. It is a reordering. Decide at the component level by default, and escalate to the page level only when the page is genuinely what changed. Teams that make the switch during the design phase of a build spend far less time later unpicking variant classes that exist only because a component could not see its own width. For teams weighing that change across an existing product, our engineering practice treats it as a design system decision first and a CSS one second.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.