I’ll admit, when container queries first shipped back in 2022, I didn’t really pay attention. I mean, why container size queries when we already have media queries? Why container style queries when custom properties inherit anyway (they don’t work with standard properties… yet)? Their use cases seemed like edge cases to me, enabling us to do things that we could already do but in a different way.

Here’s a container size queries demo by Kevin Powell. As a note, all major browsers support size queries in the following demo, but other demos in this article may require the latest Chrome.

Container style queries (with the new range syntax) demo by, uh, me:

And more recently, we’ve seen a couple more types of container queries pop up.

Container Scroll-State Queries

Container scroll-state queries came along with their unique capabilities — the ability to find out whether a container is scrollable, or is scroll-snapped to a scroll target, or has position: sticky and is ‘stuck.’ Literally, as I’m writing this, Chrome announced scrolled support, which is a bit different to scrollable.

Container scroll-state queries demo by our very own Geoff Graham:

And that’s not all we’ve got…

Anchored container queries

The latest container query feature is anchored container queries, which enable us to query fallback positions. Imagine that you anchor-position a tooltip caret to the left side of a tooltip, but then there’s no room to display the tooltip, so you flip it to the opposite side of whatever triggers it using position-try-fallbacks: flip-inline. Well, an anchored container query can detect when the tooltip position is flipped so that we can also flip the tooltip caret to the opposite side of the tooltip.

What else?

So, it got me thinking, how far can we really go with container queries? There are dozens of media queries now, so what if there were dozens of container queries as well? What could we use them for?

Get any computed value

Recently I was exploring the current and future methods of getting the value of a CSS property and using it with another property, and as you can imagine, container size queries were mentioned since they unlock container query units. I mean, have you ever added a wrapper element or defined an existing one as a container just to access container query units?

 {
  /* Gimme container query units! */
  container-type: inline-size;

   {
    width: 100cqi;
  }
}

Now, I don’t love container queries as a means of getting values because the syntax can be a bit long-winded for that (longer than the example above, and size queries in particular are a bit quirky), but the fact that we can use them to do a little more than querying is testament to how versatile they are as a feature. As an alternative, I suggested a CSS function called compute(), where if you wanted the height of something (or the “something” of anything), we could steal it from another element like this:

 {
   {
    /* Computed height of  */
    property: compute(height, self);
    /* Computed height of the parent */
    property: compute(height, inherit);
    /* Computed height of #abc element */
    property: compute(height, #abc);
  }
}

This would save us from having to implement a container size query just to use its container query units, and would also apply to all properties. Besides, a container size query wouldn’t help us to acquire the un-computed declared value that we actually typed out. For that, the inherit() function has been proposed and Roma even shows us how to use it in Chrome Canary.

To add, I really like the keyword approach and would love to see more keywords like currentColor (e.g., currentBackgroundColor has been proposed).

Still, if container queries could be extended to get the value of any CSS property, I definitely wouldn’t say no to that! The flexibility to pass properties/values between elements is way too enticing.

Query any CSS property

This feature has actually been on the slate since container style queries were first proposed, but there’s no telling when it will arrive. This container style query upgrade will enable us to query the (un-computed/declared) value of any CSS property instead of just custom properties (although you won’t be able to ‘get’ and use those values, at least as far as I know).

Any CSS property? Uh, doesn’t that make all of the other container queries redundant? Not quite, no.

Container scroll-state queries detect snapping and stickiness, for which there are no pseudo-classes — but maybe there should be? They also detect scrollability, since, for example, overflow: scroll and overflow: visible doesn’t mean that the content is actually overflowing, only that we’re allowed to scroll the container if it does. Finally, anchored container queries don’t query the position-try-fallbacks value, they detect when, for example, the position-area is flipped.

So, you know, they do a whole bunch of stuff, and that’s why this upgrade for container style queries won’t replace them. In fact, I can totally see dozens of new container query features hitting the web within the next few years.

So, what else could container queries do?

Before container queries were even a thing, great ideas were being put forward. Of course, some of them actually became container queries whereas others are still just that — great ideas that haven’t gone anywhere (again…yet?).

I’m confident that we’ll see these ideas realized at some point, either as container queries or as some other syntax. Heck, since it’s December, I’ll make it my prediction for 2026: container queries will rule 2026.

What else do you want container queries to do?

References