How Container Queries Changed The Way I Thought About Components

When container queries started becoming usable in modern browsers, the thing that interested me was not just the syntax. It was the change in how responsive decisions could be made. For years, I had been writing layouts that responded mainly to the viewport. That worked, but it always had an awkward limitation. Components do not only care about the size of the screen, they care about the space they have been given inside the layout.

That distinction matters on real websites. The same card might appear in a three-column grid, a narrow sidebar, a carousel or a featured section. The viewport might be wide in all of those situations, but the component itself might have very different amounts of space. Media queries can only tell part of that story.

The Problem With Viewport-Only Thinking

Before container queries, I usually solved this through additional classes or layout-specific CSS. A card in a sidebar would get one treatment, a card in a grid would get another and a featured version might need its own modifier. That works, but it spreads responsive behaviour across the surrounding layout. The component is no longer responsible for how it behaves. The parent layout has to keep telling it what kind of version it is.

That can get messy over time. A component starts as one pattern, then gets reused somewhere else, then needs a slightly different arrangement. Before long, the CSS has a mixture of breakpoint rules and context-specific overrides. It still works, but it becomes harder to understand why the component behaves a certain way in one location and differently somewhere else.

Container queries offer a cleaner way to think about that. The component can respond to the size of its own container. That feels much closer to how components are actually used.

A Simple Example

The basic setup starts by telling the parent element that it should act as a container. The child styles can then respond to the size of that container rather than the full viewport.

.card-wrapper {
  container-type: inline-size;
}

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

@container (min-width: 36rem) {
  .card {
    grid-template-columns: 12rem 1fr;
    align-items: center;
  }
}

In that example, the card does not care whether the screen is desktop-sized. It cares whether the wrapper is wide enough for a two-column layout. If the card is placed in a narrow sidebar, it can remain stacked. If the same card is placed in a wider content area, it can rearrange itself.

Why This Matters For Reusable Sections

This changes the way I think about reusable sections. A component becomes more self-aware. It can carry more of its own responsive behaviour, which reduces the need for layout-specific exceptions. That is particularly useful on content-managed websites where the same block or section might be used in several different contexts over time.

For WordPress blocks, this could become especially useful. A block might be inserted into a full-width area, a group block, a narrow column or a pattern. Viewport breakpoints alone do not tell me enough about those contexts. Container queries make it easier for the block to adapt based on the space it actually receives.

I do not think this removes the need for media queries. Page-level layout decisions still depend on the viewport. Navigation, major grid changes and overall page structure often need that wider view. Container queries are more useful at the component level, where the question is not how large the screen is, but how much room this specific thing has.

Being Careful With Support

Because support is still new in 2022, I would not use container queries carelessly on every project. The safe approach is to use them where they improve the experience, but avoid making the entire layout fail without them. Progressive enhancement still matters. A component should have a sensible default layout, then improve when container queries are available.

That default-first approach keeps the CSS more resilient. The stacked version of a card can work everywhere. The enhanced version can appear where the browser supports the query. That means the feature can be used without treating it as a hard requirement for the whole site.

Retrospective Thoughts

Container queries feel important because they match how modern websites are actually built. We reuse components, blocks and sections in different places. Those pieces need to behave according to their own space, not only according to the browser window.

I am still cautious about support, but I can already see where this changes day-to-day CSS. It gives me a cleaner way to write components that travel well across a website. That is the part I find exciting. Not because it makes responsive design easier in every case, but because it makes certain layout decisions belong to the component that is actually affected by them.