CSS Container Queries ഒരു കമ്പോണന്റിനെ അതിന്റെ സ്വന്തം കണ്ടെയ്നറിന്റെ വലുപ്പത്തിനനുസരിച്ച് പ്രതികരിക്കാൻ അനുവദിക്കുന്നു, മുഴുവൻ വ്യൂപോർട്ടിനും പകരം. ഇത് പ്രൊഡക്ഷനിൽ എങ്ങനെ ഫലപ്രദമായി ഉപയോഗിക്കാം എന്ന് ഈ ലേഖനം വിശദീകരിക്കുന്നു.
Media queries answer one question well: how wide is the browser window? That question turns out to be the wrong one for a huge share of real layout problems, because a component's available space depends on where it is placed — a sidebar, a modal, a three-column grid, a full-width section — not on the viewport as a whole. A card component that looks right at full width and cramped in a narrow sidebar cannot be fixed by a media query, because the viewport did not change; only the container did. Container queries close exactly this gap, and with browser support now solid, there is little reason left to work around it with JavaScript.
The Actual Problem Container Queries Solve
Component-based design systems build the same card, panel, or widget to be reused across many different contexts — a full-width hero, a narrow sidebar, a dense grid — and a real design system inevitably needs that component to look right in all of them. Media queries cannot express "when this component has less than 400px of available width," only "when the browser window has less than 400px of available width," which are frequently different values entirely. The workarounds developers built before container queries existed — duplicate component variants, JavaScript-based ResizeObserver hacks, or simply accepting an awkward layout in narrow contexts — were all more code and more fragility than the problem justified.
Basic Syntax and Setup
A container query requires explicitly declaring an element as a query container, then writing rules that respond to that specific container's size rather than the viewport.
.card-container {
container-type: inline-size;
container-name: card;
}
@container card (min-width: 400px) {
.card-title {
font-size: 1.5rem;
}
.card-layout {
display: grid;
grid-template-columns: 120px 1fr;
}
}container-type: inline-size is the setting used in the large majority of real cases, since it queries against the container's width, which is what most layout decisions actually depend on. Naming the container with container-name is optional but strongly recommended once you have more than one nested container, since it removes any ambiguity about which ancestor a given query is actually targeting.
Real Production Patterns
- A card component that switches from stacked to side-by-side layout once its container passes a width threshold, working correctly whether that card sits in a full-width feed or a narrow sidebar, with no duplicate component needed.
- A navigation component that collapses labels to icons below a certain container width, useful for components that get embedded in variable-width contexts like a resizable dashboard panel.
- Typography scaling tied to available space rather than viewport width, which more accurately reflects actual reading conditions for a component embedded in a multi-column layout.
- Container query units (
cqw,cqh,cqi) size elements relative to the container's dimensions directly, useful for maintaining proportional spacing inside a component regardless of where it is placed.
Common Mistakes When Adopting Container Queries
- Declaring every element a container "just in case." Only elements that actually need to host size-dependent children should be containers; over-applying it adds unnecessary complexity and can create confusing nested-container scoping issues.
- Forgetting that a container cannot query itself. The element with
container-typeset establishes the query context for its descendants, not for its own size-dependent styling — that still needs to happen one level up, on its parent. - Mixing container queries and media queries without a clear rule for which handles what, leading to a codebase where nobody is sure why a given breakpoint lives where it does. A reasonable default: media queries for page-level layout shifts, container queries for component-internal layout.
- Not checking real browser support for the specific project's audience before removing JavaScript-based fallbacks entirely, even though support is now solid across all major evergreen browsers.
When Container Queries Are Not the Right Tool
Page-level layout decisions — overall grid structure, whether a sidebar exists at all, top-level navigation pattern — are still genuinely viewport concerns and belong in media queries. Container queries solve the component-internal problem, not the whole-page problem, and using them for page-level decisions just relocates complexity without solving anything, since you would need to wrap the entire page in an artificial container purely to query against what is really the viewport anyway.
Frequently Asked Questions
Do I need to replace all my media queries with container queries?
No. Media queries remain the right tool for page-level layout decisions tied to the actual viewport, such as overall grid structure or whether a sidebar is shown at all. Container queries solve a different, component-level problem and work best alongside media queries, not as a wholesale replacement for them.
Is browser support good enough to use container queries in production now?
Yes, support across all major evergreen browsers has been solid for some time. For most production projects targeting current browser versions, container queries can be used without a JavaScript fallback, though it is still worth checking your specific analytics for any meaningfully sized legacy browser audience before removing an existing fallback entirely.
What is the difference between container-type: inline-size and container-type: size?
inline-size queries only the container's width, which covers the large majority of real layout needs and has fewer rendering performance implications. size queries both width and height, which is occasionally needed but requires the container to have an explicit, non-intrinsic height to work reliably, making it a less common and more constrained choice.
Can a component query its own container-type element?
No. Setting container-type on an element establishes the query context for that element's descendants, not for the element's own styling. To make an element respond to its own size, wrap it in a parent element that carries the container-type declaration instead.
Do container queries replace the need for a component-based design system?
No, they strengthen one. A design system still defines the components, their variants, and their design tokens. Container queries remove the specific limitation that previously forced teams to build separate size-specific variants of the same component, letting one component definition adapt correctly wherever it is placed.