Breakpoint vs. Container Queries: Component-Based Design
Learn the difference between designing for screen width (Breakpoints) and designing for container width (Container Queries), and how this revolutionizes component design.
The Paradigm Shift in Product Design
For the last decade, we have designed “screens”: mobile, tablet, and desktop. However, in a modern design system, we design components that live in different places. The same “Product Card” component can appear in a 3-column grid on the home page, or in a single narrow column in a sidebar.
Designing based only on screen width (Breakpoints) forces the creation of very complex and specific rules for each location. Container Queries allow the component to be “intelligent” on its own.
1. Breakpoints (Media Queries): The Global Vision
- How they work: The code asks: “How wide is the browser window?”. If it’s less than 600px, apply the mobile design.
- When to use them: For high-level structural changes, such as hiding the side menu, changing the number of columns on the web, or adjusting global margins.
- Limitation: If a component is in a narrow sidebar on a 4K monitor, the breakpoint will say “4K Monitor,” but the component only has 300px to breathe. This is where the design breaks.
2. Container Queries: The Component Vision
- How they work: The code asks: “How wide is the space where I’ve been placed?”. If my container is less than 400px, I go vertical; if it’s more, I go horizontal.
- When to use them: For the atomic design of components (cards, tables, banners, inputs). The component adapts to its context regardless of the screen size.
- UX Advantage: Guarantees readability and visual hierarchy of the component in any part of the interface, reducing visual errors and layout breakage.
Comparison: Which to choose?
| Feature | Breakpoints | Container Queries |
|---|---|---|
| Reference | Viewport Width (Screen). | Parent Container Width. |
| Control Level | Global (Page). | Granular (Component). |
| Ideal Use | High-level Layout (Grid). | Low-level UI (Atomic). |
| Portability | Low (Component depends on the page). | High (Component is autonomous). |
How to Design for Container Queries in Figma
Figma doesn’t have a native feature called “Container Queries” yet, but you can simulate this behavior through the strategic use of Auto Layout and the “Fill Container” property.
- Design your component with Auto Layout and notice how it behaves when you stretch it independently of the main frame.
- Use the “Wrap” property so elements jump to a new line automatically based on their width, emulating Container Queries logic.
- Add annotations in the handoff: “This component should go vertical when its width drops below 450px.”
Benefits for the Design System
- More Reusable Components: You don’t need separate variants for each screen size; a single smart variant adapts to everything.
- Cleaner Code: Fewer specific media queries scattered throughout the CSS.
- Resilient Design: The design “doesn’t break” if the developer decides to move a component later.
Mentor’s Tips
- Design for the “Worst-case scenario”: Test your component in ridiculously narrow and ridiculously wide containers. You’ll quickly see where you need to apply a Container Query rule.
- Don’t abandon Breakpoints: Keep using them for the general structure of your web (navbars, footers, main grids). They are complementary, not substitutes.
- The container name matters: In the code, the component must know who its “parent” is so it can measure itself against it. Reflect this in your layer hierarchy in Figma.
Useful Resources and Tools
- MDN Web Docs: CSS Container Queries
- Ahmad Shadeed: A Guide to Container Queries
- CSS Tricks: Container Queries are finally here
- Articles: Why designers should care about Container Queries
layout-grid-vs-intrinsic intrinsic-sizing auto-layout-constraints responsive-scaling