Stop Fixing the Viewport: Let Components Think for Themselves

We've been lied to. Not maliciously, but the gospel of 'mobile-first' and 'breakpoints at 375, 768, 1024' has led us astray. The viewport is a symptom, not the disease. The real unit of responsive design is the container. If you're still designing components that only know how to behave based on the width of the entire browser window, you're building fragile systems that break the moment you put a sidebar next to a card or a widget in a footer.

Imagine you're a UI/UX designer at a mid-sized SaaS company. You've been tasked with revamping the dashboard. The team has a component library, but every component is tied to viewport breakpoints. The 'data summary card' looks great in the main column, but when the same card is placed in a narrow sidebar, it collapses into an unreadable mess. You've tried media queries, but it's a whack-a-mole game. This is where we stop and rethink.

The Container Is the New Viewport

Here's the contrarian take: stop obsessing over the viewport width and start thinking about the space a component actually lives in. CSS container queries (@container) let a component respond to the size of its parent container, not the viewport. This feature is Baseline Widely available, in browsers since February 2023 (MDN Web Docs (@container)). That means it's time to use it. Our dashboard scenario: the same 'summary card' can now be designed to adapt to a narrow sidebar or a wide content area, simply by defining container queries based on the parent's width. This is a fundamental shift in how we think about responsive design.

But it's not just about layout. The container query length units—like cqw (1% of container width) or cqi (1% of container inline size)—allow you to size typography and spacing relative to the container, not the viewport (MDN Web Docs (container queries guide)). This is a game-changer for consistency. In our dashboard, the card's font-size can scale fluidly with the container, ensuring readability whether it's in a 300px sidebar or a 900px main column. And because it's tied to the container, you avoid the jarring 'jump' that often happens at viewport breakpoints.

Don't Forget the Human Behind the Screen

While we're busy making components flexible, we must not forget the actual humans using the site. Accessibility isn't a checkbox; it's a non-negotiable. The WebAIM Million study of the top 1,000,000 home pages found that 95.9% had detected WCAG 2 failures (WebAIM Million). That's an embarrassing stat. The most common issue? Low-contrast text, present on 83.9% of home pages (WebAIM Million). So, as we build our beautiful, container-query-driven components, we need to bake in accessibility from the start.

For our dashboard, that means: ensure text contrast meets at least 4.5:1 for normal text (WCAG 2.1 (AA)). Make sure touch targets are at least 44 by 44 pixels (WCAG 2.1 (AA))—and note that Apple recommends 44x44 points, while Android suggests 48x48 dp (Apple Human Interface Guidelines; Android Developers (accessibility)). And don't rely on color alone to convey information, because about 1 in 12 men have color vision deficiency (NEI (National Eye Institute)). Use labels and icons alongside color.

Also, think about keyboard users. WCAG 2.1 requires all functionality to be operable via keyboard (W3C WCAG 2.1 Understanding Keyboard). And a visible focus indicator is essential (W3C WCAG 2.1 Understanding Focus Visible). In our component, we'll add a clear focus ring, and we'll make sure it isn't obscured by sticky headers or other elements, per WCAG 2.2's Focus Not Obscured (Minimum) (W3C WCAG 2.2 Understanding Focus Not Obscured (Minimum)).

Performance Is a UX Feature

Users don't have infinite patience. Nielsen Norman Group research shows that 0.1 second is the limit for feeling instantaneous, 1.0 second keeps the flow of thought uninterrupted, and 10 seconds is the limit for attention (Nielsen Norman Group). So, performance is a core part of UX. Google's Core Web Vitals give us specific targets: LCP should be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less (web.dev (Web Vitals)).

In our dashboard, we'll optimize images. Use the srcset and sizes attributes to serve appropriate resolutions, and set width and height on images to prevent layout shift (MDN Web Docs). We'll also use modern formats: WebP is 25-35% smaller than JPEG (MDN Web Docs (Image types)), and AVIF is about 50% smaller than JPEG, but with less support, so use <picture> for fallbacks (MDN Web Docs (Image types)). And we can lazy-load offscreen images with loading="lazy" (MDN Web Docs).

For fonts, use font-display: swap to ensure text is visible immediately while the custom font loads (MDN Web Docs (font-display)). This prevents invisible text and layout shifts.

Embrace the Container, but Keep It Semantic

With great power comes great responsibility. Container queries are fantastic, but they can lead to components that are too isolated from the document structure. We must keep our HTML semantic. Use header, nav, main, article, section, footer to convey structure to assistive tech (MDN Web Docs (Structuring documents)). A div has no semantic value; don't wrap everything in one.

In our dashboard, we'll structure each widget as an article with a heading. This helps screen reader users navigate. And with container queries, the same article can adapt its layout based on its container, but the semantic meaning stays intact.

Another modern tool: the :has() relational pseudo-class is now Baseline Widely available (since December 2023) (MDN Web Docs (:has)). It lets us style a parent based on its children. For example, if a card contains a featured image, we can adjust the layout accordingly, without adding extra classes. This is powerful for component-based design.

And don't forget about subgrid, which is Baseline Widely available since September 2023 (MDN Web Docs (Subgrid)). It lets nested grids align with the parent grid, which is perfect for aligning cards in a dashboard where the header and footer need to line up across components.

But remember: breakpoints should be added when content demands them, not at fixed device sizes (MDN Web Docs). And common reference values like 375px, 768px, 1024px are just starting points—you should test with real content.

The One Thing to Remember

Stop designing for the viewport; design for the container. Container queries, combined with a solid accessibility and performance baseline, will make your UI/UX truly responsive—not just to screen size, but to context. That's the future of web design.

Quick tip: Start by converting one component in your library to a container query and see how it behaves in different contexts. You'll never go back.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Web/CSS/@container
• MDN Web Docs (container queries guide) - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
• WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
• WebAIM Million - https://webaim.org/projects/million/
• web.dev (Web Vitals) - https://web.dev/articles/vitals
• Nielsen Norman Group - https://www.nngroup.com/articles/response-times-3-important-limits/