Container queries allow you to style elements based on the size of their parent container rather than the viewport. Using the @container rule, you can create truly reusable, context-aware components that adapt to any layout slot. First define a containment context with container-type: inline-size on the parent, then write @container (min-width: 400px) { ... } to apply styles when the container meets the condition.

@media queries respond to the viewport (browser window) size — great for page-level layouts. @container queries respond to a specific parent element's size — perfect for reusable components that need to adapt regardless of where they're placed. With container queries, a card component can automatically switch layout whether it's in a wide main column or a narrow sidebar, without any extra classes or JavaScript.

container-type: inline-size creates a containment context that tracks the element's inline dimension (width in horizontal writing modes). This is the most common setting and sufficient for most use cases. Other values: size tracks both width and height, normal disables containment (default). Using inline-size is preferred for performance since it only monitors one axis.

container-name assigns a name to your containment context, letting you target a specific container in nested layouts. Example: container-name: sidebar on the parent, then @container sidebar (min-width: 300px) { ... } targets only that container. Without a name, @container queries the nearest ancestor with a containment context. Named containers prevent ambiguity in complex nested structures.

Container queries are supported in all modern browsers: Chrome 105+, Safari 16+, Firefox 110+, and Edge 105+. Global support is now over 93% (as of 2025). They're safe for production use. For older browsers, you can use @supports (container-type: inline-size) to provide fallback styles or polyfill with JavaScript.

Absolutely! You can define multiple @container rules with different breakpoints — just like media queries. For example, you might have rules for max-width: 350px, min-width: 350px and max-width: 600px, and min-width: 600px to create three distinct layout tiers. The most specific matching rule applies, following standard CSS cascade principles.

Common scenarios include: reusable card components that switch between horizontal/vertical layouts, adaptive form fields that resize based on their container, responsive data tables that collapse columns intelligently, dashboard widgets that reorganize content based on available space, and design system components that work consistently across different page templates without custom overrides.

Container queries are designed to be performant. Using container-type: inline-size has minimal overhead. However, container-type: size (tracking both axes) requires more computation. Best practices: only apply containment to elements that need it, prefer inline-size over size when possible, and avoid deeply nested container queries (grandparent + parent + child all having containment) unless necessary.

Yes! Container queries and media queries work together beautifully. Use @media for page-level layout decisions (e.g., sidebar position, global font scaling) and @container for component-level adaptations (e.g., card orientation, internal grid columns). This layered approach gives you precise control at every level of your design — the best of both worlds.

Container queries introduce container query length units: cqw (1% of container width), cqh (1% of container height), cqmin, and cqmax. These work like viewport units (vw, vh) but are relative to the container, not the viewport. For example, font-size: 5cqw makes text scale with the container's width — incredibly useful for fluid component typography.