What are CSS container queries and what problem do they solve?
This tests component-level responsive awareness. A strong answer states container queries style elements based on their container size, letting components adapt regardless of viewport. Red flag: believing media queries alone solve component context adaptation.
What's really being asked
Whether you understand the architectural shift from page-level responsive design to container-level responsive design, and if you can articulate why viewport-based media queries break component reusability in modern design systems.
The full answer
Four things in order. First, a clear definition that container queries are at-rules using the container dimensions instead of the viewport. Second, the specific problem they solve which is that a reusable component like a card does not know its layout context, so viewport media queries force you to write overrides for every possible page location. Third, the mechanics of creating a containment context with container-type set to size or inline-size so the browser knows which dimensions to track. Fourth, a concrete component example that shows adaptation based on the container width rather than the device width.
The mistakes people make
Three red flags to avoid. First, saying container queries are just nested media queries or a syntax improvement without explaining the container versus viewport distinction. Second, claiming you can solve the same problem with media queries by adding extra CSS classes per page section, which misses the point of true component encapsulation. Third, forgetting to mention containment context setup and implying container queries work on any parent automatically.
What usually comes next
An interviewer might ask about container query length units like cqw and cqh and how they differ from viewport units. They might ask about the performance implications of containment and how layout containment prevents unwanted reflows from escaping the container. They could also ask about style container queries or scroll-state queries as extensions of the same concept.
A concrete example
A product card component that displays a stacked layout with small text in a narrow sidebar, but switches to a horizontal layout with larger typography when placed in a wide main content area. With container queries, the card uses a container-type of inline-size on its wrapper and an at-rule that checks if the container width exceeds 400 pixels to change flex-direction and font-size. The same card component works in both locations without any knowledge of the page structure, which is impossible with viewport media queries because both layouts might exist on the same screen simultaneously.
Interview question
A reusable card must switch layout when placed in a sidebar or main area on the same screen. Which approach correctly handles this?
- a.Query the card with an @container rule using its own width, because container queries do not require a containment context to be established first
- b.Use a viewport media query and override with page-specific classes when the card appears in the sidebar
- c.Set container-type: inline-size on the card's wrapper and use an @container rule to style it when the wrapper exceeds 400 pixelsCorrect
- d.Nest a standard @media query inside the card's CSS so it evaluates the card's bounding box instead of the viewport
Why? this is the answer
Option C is correct because it establishes a containment context with container-type so the browser tracks the wrapper's dimensions, letting the component adapt independently of viewport size. Option B is tempting but wrong: viewport media queries cannot distinguish between a sidebar and main area on the same screen, forcing brittle page-specific overrides.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #css
- #container-queries
- #responsive-design
- #design-systems
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles