Why this matters in 2026
Container queries flip responsive design on its head. Instead of asking "how wide is the viewport?", you ask "how wide is this component's container?". That's the difference between a layout that breaks in a sidebar versus one that adapts gracefully. Spacing is the first place you notice the difference: tight gaps on small containers, roomy gaps on wide ones — all without a single media query.
The logic
container-type: inline-size tells the browser to track the element's width as a queryable dimension. The container-name (e.g., spacing-demo) gives it a handle. Then @container spacing-demo (min-width: 28rem) applies styles only when that container exceeds 28rem. The gap property scales incrementally: 1rem → 1.5rem → 2rem as the container grows.
Unlike media queries (which check viewport width), container queries check the element's own width. That means the same card list can have tight spacing in a narrow sidebar and generous spacing in a full-width main area.
Accessibility & performance
Container queries are purely presentational — they don't change semantics or keyboard navigation. Ensure your card list uses semantic HTML (e.g., <ul> + <li>) if the cards represent a list. Performance-wise, container queries are GPU-friendly: the browser recalculates them during layout, not paint. On very old browsers without CQ support, provide a sensible default gap that works at all sizes.
sidebar-spacing, card-list) to avoid conflicts in large codebases.