I have been thinking more this year about responsive design at the component level rather than only at the viewport level.
Media queries are still useful, and I use them constantly. The problem is that they answer a fairly broad question: how wide is the browser? They do not tell me how much space a component actually has inside the layout. A card inside a narrow sidebar and a card inside a wide grid can exist at the same viewport width but need very different treatment.
That is the part I have started paying more attention to. Even before browser support makes container-based CSS a normal part of daily work, the thinking is useful. A component should respond to the space it is given, not just to the width of the screen.
Where Viewport Breakpoints Start To Feel Blunt
Viewport breakpoints work well for large layout decisions. A two-column page becomes one column. A navigation changes shape. A hero section adjusts spacing. Those decisions are still tied to the overall screen width, and that makes sense.
The awkwardness appears inside reusable components. A card may be used in a three-column grid, a related-content section, a sidebar or a carousel. The viewport width might be the same in each case, but the card width is not. If all of the card’s behaviour is controlled by global breakpoints, the component can feel right in one context and wrong in another.
That often leads to extra modifier classes or page-specific CSS. Sometimes that is fine, but too much of it makes the component less portable. I would rather design the card with its likely containers in mind from the beginning.
Designing Components Around Available Space
The practical change is to think about the component’s own limits. At what width does the image need to move above the text? When does the heading need smaller type? When should metadata stack instead of sitting in a row? Those are component questions, even if the CSS still has to be written with media queries for now.
This also affects Figma and design discussions. A component should be tested in the places it will actually appear. A card drawn at one perfect width does not tell us much about how it behaves across a real website. I want to see it inside a grid, inside a sidebar and inside the narrowest space it is likely to occupy.
That gives development a better starting point. Instead of building a component and discovering its weaknesses later, the design has already considered how the component behaves over time and across templates.
Keeping The CSS Maintainable
Until container queries are something I can rely on everywhere, I still need practical CSS. That means using sensible layout rules, avoiding overly specific selectors and keeping components as independent as possible. Flexbox and Grid help here because they allow a component to adapt within the space available without every change needing a new breakpoint.
I also try to avoid tying a component too closely to one page template. If a card class only works inside one parent layout, it is not really reusable. That may be acceptable for a unique section, but it should be a deliberate decision rather than something that happens because the CSS grew around one page.
What I Took From It
The useful shift is not only technical. It changes how I think about responsive design. The screen size matters, but the component’s context matters too. A website is made from parts that move into different spaces, and those parts need to behave well wherever they are used.
Even before container-based CSS becomes part of everyday support, thinking this way leads to better components. It makes me test layouts more honestly and design reusable sections with fewer hidden assumptions. That is the kind of change that pays off later, when a client wants the same component used somewhere the original design did not anticipate.