I used to think about responsive design mostly through the size of the browser window. That made sense for a long time because media queries gave us a practical way to move from desktop layouts to tablet layouts and then down to mobile. The whole page responded to the viewport, and for many websites that was enough.
The problem I kept running into was that components do not always live in predictable places. A card might appear in a three-column grid on one page, a narrow sidebar on another and a full-width feature area somewhere else. The viewport might be exactly the same in each case, but the space available to the component is completely different. That is where viewport-based thinking starts to feel too blunt.
This changed the way I approached reusable front-end sections. Instead of asking how a component should behave on a tablet or laptop, I started asking how it should behave when its own available space changes. That sounds like a small shift, but it affects how the CSS is structured and how confidently a component can be reused across a site.
The Problem With Page-Level Thinking
A component can look finished when it is designed for one page. It has the right image size, the title wraps neatly and the button sits in a sensible place. Then it is reused somewhere else and the same component starts to feel awkward. The image takes too much vertical space, the title wraps earlier than expected or the button no longer feels connected to the content above it.
The old answer was often to create more modifier classes. There would be a card, then a card for the sidebar, then a card for the feature section, then another version for a landing page. That works for a while, but eventually the component stops feeling like one component. It becomes a collection of exceptions that all need remembering.
I started preferring CSS that allowed the component to respond to its own container where possible. That means the same component can make smaller layout decisions based on where it has been placed, rather than waiting for the whole viewport to cross a breakpoint. It feels closer to how the design behaves in real use.
This is particularly useful inside WordPress builds where blocks and patterns can be reused in different page contexts. Editors do not always think in terms of viewport breakpoints. They think in terms of placing a section somewhere useful. The component needs to handle that without creating a layout problem the editor cannot understand.
A Simple Example
A common example is a card that should move from a stacked layout to a horizontal layout when there is enough space. I do not really care whether the page is 900px wide or 1200px wide. I care whether the card itself has enough room to support the horizontal version.
.card-wrapper {
container-type: inline-size;
}
.card {
display: grid;
gap: 1rem;
}
@container (min-width: 32rem) {
.card {
grid-template-columns: 12rem 1fr;
align-items: start;
}
}The wrapper defines the container. The card then changes when the container is wide enough, not when the viewport is wide enough. That makes the component easier to place in different layouts because its behaviour follows the space it has been given.
I like this because the CSS starts to describe the component more honestly. The decision is not really about a phone, tablet or desktop. The decision is about whether the content has enough room to sit side by side. That is a better question, and it usually produces a better component.
What This Changes In Design Reviews
This also changes how I review designs. Rather than only checking a few viewport sizes, I want to see how a component behaves in narrow and wide containers. A testimonial block might work beautifully in a full-width section but feel heavy inside a two-column layout. A card might need a different image treatment when it is used in a dense listing. Those behaviours are part of the component, not afterthoughts.
It also makes conversations with designers more practical. Instead of saying that something breaks at a certain screen width, I can explain that the component needs a rule for when its available space changes. That is usually closer to the design problem. The page might still be responsive, but the component needs its own smaller set of decisions.
There is a maintenance benefit too. If the component knows how to adapt to its own space, future layouts become less risky. A developer can move it into a new page structure without immediately creating a new modifier. An editor can reuse a pattern with more confidence because the component has sensible behaviour built in.
Where I Still Use Media Queries
I still use media queries. They are not going away and they remain useful for page-level decisions. The overall navigation, major layout regions and site-wide spacing often still need viewport-based rules. The difference is that I no longer expect media queries to solve every responsive problem.
For me, the useful split is fairly simple. The page can respond to the viewport, but the component should respond to the space it occupies. When those two ideas work together, the layout becomes easier to understand. The page decides the big structure, and each component decides how to behave inside that structure.
This is not about using new CSS for the sake of it. It is about reducing the number of fragile assumptions inside a build. If a component can only work in the one place it was originally designed for, it is not really reusable. It is a section with a familiar class name.
Retrospective Thoughts
I think component-level responsive thinking is one of the more practical shifts in front-end work at the moment. It is not as visually dramatic as some new design trend, but it solves a problem that appears constantly in real projects. Websites are made of reusable parts, and those parts need to behave properly outside the first layout they were designed for.
The more I work with blocks, patterns and reusable sections, the more I want CSS that reflects how those pieces are actually used. Container-based decisions help with that. They make components more independent, more predictable and easier to move around without breaking the design.
That is the real value for me. A component should not need a developer standing beside it every time it is reused. It should carry enough of its own behaviour to survive the layout it has been placed in.