Because the card is styling itself based on the screen width, not its own width. On a wide screen the card assumes it has room. Drop it into a narrow sidebar and it keeps the wide layout, because the browser window did not change. Container queries fix exactly this.
This is the oldest annoyance in responsive design. You build a component once, it works beautifully in the main column, and then someone reuses it somewhere narrower and it falls apart. The usual patch is a second version of the component with different classes, which doubles the maintenance forever.
Container queries remove the need for that second version. The component asks how much space it has been given and styles itself accordingly. It is a small change in syntax and a large change in how you think about layout.
Container queries let an element apply styles based on the size of its parent container rather than the size of the viewport. You mark an element as a query container, then write rules that respond to that container's width. The component becomes portable, because its layout logic travels with it.
The mechanism has two halves. First you declare a containment context on the parent using the container-type property. Then you write an @container rule that tests a condition, much like a media query tests the viewport.
MDN documents three values for container-type. The value size queries both inline and block dimensions, inline-size queries only the inline dimension, and normal is the default, where the element is not a size query container at all. In practice inline-size is what you want almost every time, because querying block size requires the browser to constrain height in ways that usually cause more problems than they solve.
You can also name a container. MDN shows the pattern of setting container-name: sidebar alongside the type, then writing @container sidebar (width > 700px) to target that specific container. There is a shorthand too, written as container: sidebar / inline-size.
A media query asks about the browser window. A container query asks about the box the element sits in. That is the entire difference, and it changes everything, because a component can now be correct in every context without knowing anything about the page it lives on.
Media queries describe the device. They were designed when the question was phone versus tablet versus desktop, and for page level decisions they are still exactly right. Should the navigation collapse? Should the page switch from one column to two? Those are viewport questions.
Container queries describe the slot. Should this card stack its image above the text or beside it? That depends on how wide the card is, which has nothing to do with the screen. A card can be 300 pixels wide on a 1600 pixel monitor if it sits in a narrow rail.
The two are not rivals. In our builds we use media queries for page structure and container queries for components inside that structure. Getting the boundary right is most of the skill, and it maps closely to how we think about choosing responsive breakpoints in the first place.
Yes, without a fallback for most audiences. Can I Use reports 92.6% global support for CSS container queries. Chrome shipped full support in version 106 and Safari in version 16.0, both in 2022, with Firefox following in version 110 in 2023. That means every current browser engine has supported this for years.
Baseline is the cleaner way to think about readiness. Google's web.dev documentation defines a feature as Newly available once it "is supported by all of the core browsers, and is therefore interoperable," and as Widely available after "30 months have passed since the newly interoperable date." The core browser set is Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.
Container queries reached interoperability across those engines in 2023, which puts them well past the 30 month mark. This is not a cutting edge feature you are gambling on. It is an ordinary part of CSS that a lot of teams simply never got around to adopting.
The remaining gap is old browsers on old devices. If your analytics show meaningful traffic from browsers that predate 2023, write your default styles as the narrow layout and let container queries enhance upward. Those users get a single column card, which is a perfectly acceptable result rather than a broken one.
Set container-type: inline-size on the wrapper, then write @container (width > 700px) and put your wider layout rules inside it. MDN gives this exact pattern, showing an @container (width > 700px) block that increases a heading to font-size: 2em when the container is wide enough.
The important discipline is choosing the right wrapper. The query container has to be an ancestor of the thing you are styling, and it cannot be the element itself. A card cannot query its own width. So the usual shape is a wrapper div that carries the containment, with the card markup inside it.
Write the narrow layout as your base styles, then use the container query to add the wide layout. This mirrors mobile-first thinking applied at the component level rather than the page level, and it means the fallback is automatically sensible.
Name your containers once you have more than a couple. An unnamed query resolves against the nearest ancestor with containment, which is convenient until you nest two containers and the nearest one is not the one you meant. Named containers make the intent explicit and the bug disappear.
Container query units let you size things as a percentage of the container instead of the viewport. MDN documents six of them. The unit cqw is 1% of the container's width, cqh is 1% of its height, cqi is 1% of its inline size, cqb is 1% of its block size, and cqmin and cqmax take the smaller and larger of those.
The practical use is fluid typography inside a component. MDN shows cqi being used to set a heading's font size from the container's inline size. A card headline can shrink when the card is narrow and grow when it is wide, without a single breakpoint.
Used carelessly these units produce text that is unreadable at extremes, so clamp them. Wrapping a container unit in a CSS clamp() with a sensible minimum and maximum gives you fluid scaling that never becomes absurd. That combination is where most of the real value sits.
Beyond size, the specification has grown. MDN notes that style queries, scroll-state queries, and anchored container queries exist as separate query types with their own guides. Those are newer and worth checking support for individually before you rely on them.
Yes, through custom code rather than the Designer's native controls. Webflow's visual breakpoint system is viewport based, so container queries live in a custom code block or an embedded stylesheet. That is a small tradeoff for components that stop breaking when clients reuse them.
This matters more on Webflow projects than on hand-coded ones, because Webflow sites get edited by non-developers. A marketer drags a testimonial component from the main column into a narrow sidebar. On a media query build it breaks and someone calls us. On a container query build it just works.
The setup is a class on the wrapper, the containment declared in a global custom code block, and the query rules alongside it. Keep all of it in one place so the next person can find it. We go deeper on doing this safely in our guide to using custom code in Webflow without breaking your site.
One caution. Because the rules live outside the Designer, the Designer canvas will not preview them. Check the published or staging site rather than trusting the canvas, or you will spend an hour debugging something that was already working.
Use a media query whenever the decision genuinely depends on the device or the window. Navigation collapsing, page level column counts, print styles, and anything driven by user preference such as reduced motion or colour scheme all belong to media queries. Those are not container questions and never will be.
There is also a performance consideration. Declaring containment changes how the browser handles layout for that subtree. That is usually a benefit, because it lets the browser skip work outside the container, but wrapping every element on the page in a query container is wasted overhead. Apply containment to the components that actually need it.
Nesting is the other limit. Deeply nested query containers get hard to reason about quickly. If you find yourself three containers deep and unsure which one a query resolves against, the layout probably needs simplifying more than it needs another query.
Our rule is simple. If the answer to "what should change here" is about the page, use a media query. If it is about the component, use a container query.
They make components genuinely self-contained. A component that carries its own responsive logic can be dropped anywhere without a review of what surrounds it. That is the property a design system is supposed to have and rarely does when layout rules live at the page level.
The knock-on effect is fewer variants. Teams commonly ship a wide card, a narrow card, and a compact card as three separate components because each was built against a different viewport assumption. One container aware card replaces all three, and every future fix happens once instead of three times.
It also changes documentation. Instead of writing "use the compact variant in the sidebar," you write the width ranges the component handles and let it decide. That is a shorter document and a far more reliable one, which fits how we think about building a design system generally.
The honest catch is that retrofitting an existing system takes real effort. You cannot sprinkle container queries onto a codebase built entirely around viewport breakpoints and expect a clean result. Adopt them on new components first and convert old ones when you are already touching them.
Start using them on new components today. Support is not the blocker it was, the syntax is stable, and the payoff is components that stop breaking when someone moves them. Do not rewrite your whole stylesheet this month. Convert the components that have already caused you trouble, and let the rest follow naturally.
The best first candidate is whichever component you have already duplicated because it needed to work in two widths. That duplication is the exact problem container queries were designed to remove, and collapsing it back into one component is a satisfying afternoon of work.
If you have a component library that keeps breaking when content moves around, we are happy to look at it with you and work out which pieces are worth converting first. Reach out through phoenix.studio and show us the component that keeps causing trouble.
Tell us where you want to go. We'll tell you how we'd get you there.