When CSS container queries landed in the spec back in 2022, I brushed them off. I was already juggling media queries and custom properties, and another layer of conditional logic did not sound like a win. I had them filed under “nice to have for edge cases,” which turned out to be wrong. As of Chrome 144 you can query so much more than inline-size that the way I build components has genuinely changed.
From size to state
Size queries came first, and the idea was simple enough: query the parent instead of the viewport. That fixed the card problem, where the same card needs one layout in a sidebar and another in the main column. Since then, scroll-state queries and anchored container queries have arrived, and both cover ground that used to take a pile of JavaScript.
/* The 'Naive' Size Query Approach */
.container {
container-type: inline-size;
}
@container (min-width: 400px) {
.card {
display: grid;
grid-template-columns: 1fr 2fr;
}
}Scroll-state queries
Detecting when an element is “stuck” under position: sticky has always been one of the uglier jobs in a WordPress theme or a busy WooCommerce dashboard. The usual answer is an IntersectionObserver with a 0px threshold, which works but never feels right. Scroll-state queries let you ask CSS directly whether a container is scrollable, or whether it is currently snapped to a target.
Chrome recently added scrolled support, which reports the current state of the scroll rather than whether a scrollbar exists. Anyone who has tried to drop a shadow on a header the moment scrolling starts knows what the JavaScript version costs you in timing bugs and layout shifts. In CSS it is one condition and there is no script to run.
Style queries, and the compute() proposal
Style queries get misread a lot. The usual objection is “why query a custom property when it inherits anyway?” Inheritance is not the point. What you get is conditional styling keyed to that property, with no class name to invent and nothing to toggle. The component logic sits in the stylesheet instead of being hardcoded into a PHP template or passed down as React props.
/* Style Query Example */
@container style(--theme: dark) {
.component {
background: #1a1a1a;
color: #fff;
}
}The one I am watching is the proposal for a compute() function. It would let you take the computed height of one element and use it in another, with no JavaScript in between. If you have ever measured an element in a script purely to size its neighbor, you know why that is worth something.
The anchored query gotcha
Anchored container queries are the newest of the three, and they exist for UI like tooltips. With position-try-fallbacks in play, the browser may flip a tooltip from above its anchor to below it so the thing stays on screen. Until now the little arrow kept pointing the old way. An anchored query sees the flip, so the arrow can turn with it.
If container queries are eating hours you do not have, or you are tired of maintaining 500 lines of scroll-detecting JavaScript, that is work I can take on. I have been doing WordPress and CSS since the 4.x days, and refactoring legacy stylesheets into container-based components is a good chunk of the work.
Where this leaves media queries
Media queries are not going anywhere, but they are no longer where most of the conditional logic belongs. If a site leans entirely on @media (max-width: 768px), every component is being sized by a number that has nothing to do with the space it actually sits in. Container queries fix that, and a component you write once really does work in the sidebar and in the main column.
