Detailed explanation
Container queries let CSS adapt a component to the space available inside a containing element, rather than only to the browser viewport. This matters for reusable components: the same card might appear in a narrow sidebar, a wide content area, or a dashboard grid on the same screen. A viewport breakpoint cannot distinguish those placements, but a container query can give each card an appropriate layout independently.
Media queries use @media to test properties of the viewport or user environment. Width-based media queries typically respond to viewport width, while other media features cover preferences such as reduced motion and capabilities such as hover support. Size container queries use @container to test an eligible ancestor container. That ancestor does not have to be the immediate parent. Media queries therefore remain useful for page-level layouts and environment settings, while container queries support local, component-level responsiveness; neither replaces the other.
In the example, .card-container { container-type: inline-size; container-name: card; } establishes and names a size-query container. Inline-size containment enables queries along its inline axis, which corresponds to width in typical horizontal writing modes, while allowing its block size to depend on content. Then @container card (min-width: 400px) { .card { flex-direction: row; } } applies when the selected ancestor named card has a content-box width of at least 400px. The .card must already use display: flex for flex-direction to affect its layout. Without a container name, the browser selects the nearest ancestor eligible for the queried feature.
Under the hood, containment limits how descendant sizing influences the queried container dimension, helping avoid circular dependencies between a query and the layout changes it triggers. A container cannot use its own size query to style itself; the rule targets descendants using an eligible ancestor. Interviewers usually look for this ancestor relationship, correct container setup, and a practical reuse example. Container queries also include style queries, but size queries are the central concept in this comparison.
Key points to remember
- Width-based media queries test the viewport; size container queries test an eligible ancestor container.
- Use container-type: inline-size for inline-axis size queries, usually width in horizontal writing modes.
- An optional container-name lets @container select a named eligible ancestor.
- Container queries enable the same component to adapt independently in different page regions.
- Use media queries for global responsiveness and environment preferences, alongside container queries for local layouts.
Common mistakes candidates make
- Assuming all media queries check screen size, ignoring features such as prefers-reduced-motion and hover.
- Writing a size-based @container rule without establishing an eligible ancestor using container-type.
- Expecting a container to style itself through its own size query, rather than styling its descendants.
Likely follow-up questions
How do container-type: inline-size and container-type: size differ?
inline-size enables size queries along the inline axis, while size enables them along both inline and block axes. Two-axis size containment requires more care because the container cannot rely on its contents to determine its size in either axis.
What happens when query containers are nested?
For each matched element, an unnamed query selects the nearest ancestor eligible for the queried feature. A named query selects the nearest eligible ancestor with that name; it does not keep searching outward merely because the selected container fails the size condition.
How can you provide a fallback for browsers without container-query support?
Start with usable base styles, such as a stacked card layout, and enhance them with @container rules. You can use @supports (container-type: inline-size) to gate related enhancements, and add media-query fallbacks where useful.
Interview tip: Contrast viewport-level and component-level responsiveness, then explain the supplied card example and why it works differently in a sidebar and a main column.