Container Query Discussion

Right now, we have the power to write CSS that only applies when the browser window itself is at certain widths or heights. Breakpoints, as it were. Super useful. What we don’t have (natively) is the ability to write conditional CSS based on any particular elements (or “containers”) properties.

It’s going on 2 years since the RICG decided to tackle this. I’m not exactly sure what the status is there. It seems a bit on pause, but that doesn’t mean the entire discussion is on pause.

From what I hear, and echo, the refrain amongst front-end devs is: if I had container queries available, 90% of the media queries I write would be container queries. The thought being, you’re usually trying to adjust some particular element’s properties that are tied to something a bit more scoped than the entire browser window.

Ethan Marcotte recently wrote:

I don’t want to suggest that the technical challenges of specifying container queries are in any way easy. But some kind of movement would be deeply appreciated by the entire responsive design community. Speaking just for myself, I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever’s coming next.

Hear hear.

He pointed to some of his own work in which modules that are in extremely different situations that aren’t directly related to the viewport, but more directly related to a parent container.

But now lately, in a wacky surprise twist, there has been a good bit of “hmmmm, perhaps we don’t need these as much as we think we do” going on.

For instance, Dave Rupert, while playing with CSS Grid Layout, found he was able to ditch some media queries entirely:

I refactored a ~50 line Flexbox grid to just ~5 lines of CSS with CSS Grid. … The best part is, we don’t need media queries! This will save a lot of code down the line. In this particular project, we actually have three Flexbox grids with slightly different breakpoints. The auto-fill keyword auto-generates columns when space is available.

See the Pen Flexbox Grid vs. CSS Grid by Dave Rupert (@davatron5000) on CodePen.

Flexbox can do some really fancy dancing with its ability to wrap, its ability to be told if it can grow or not, and how much and to what limits gives us a lot of control without explicit media queries.

Grid gives us even more tools with things like auto layout, minmax(), and keywords like min-content and auto-fill. The fact that you can nest Flex containers and Grid containers any-which-way makes for some powerful possibilities.

For example, see Jonathan Snook playing around (who, self-admittedly, is just starting to wrap his head around these types of layouts) have a lot of success in container-query-like control over some modules.

Paul Robert Lloyd explictly questions the need for container queries:

In my mind, container queries appear to be yesterday’s answer to today’s problems. I’d much rather we use the great new tools we have, and embrace a future that’s finally here.

Even rebuilding Ethan’s example with only a page-layout affecting media query:

See the Pen Rebuilding The Toast’s Recirculation Module by Paul Lloyd (@paulrobertlloyd) on CodePen.

Jeremy Keith filling in as baby bear:

… this is a good well-reasoned post about why container queries might not be the all-healing solution for our responsive design problems. Thing is, I don’t think container queries are trying to be an all-encompassing solution, but rather a very useful solution for one particular class of problem.

So I don’t really see container queries competing with, say, grid layout (any more than grid layout is competing with flexbox), but rather one more tool that would be really useful to have in our arsenal.

Even container queries can’t solve all RWD problems, of course. As Paul said:

The final reason I question the need for container queries is that a change in layout sometimes requires a change in behavior, too. If accomplishing this involves restructuring the DOM, we’re essentially swapping one component for another.

So yes, newfangled layout tools may save us in many situations from needing container queries specifically for layout changes. But layout isn’t the only thing that may need to change in an element depending on the container situation. Ethan responds:

Depending on a module’s placement, height, and width, I might want to change several different aspects of its design. These changes would include, but aren’t limited to:

1. Visual weight. Depending on where the module’s positioned, I’ll frequently want to change how visually prominent it is. This might include changing its color, its background color, or the size of individual elements within it, all depending on the space allocated to the module.
2. Typography. Related to that last point, I frequently need to change the typography of an element, based on the size of its container. Grid Layout and flexbox aren’t any help here, sadly; and as much as I love flexible typography—Trent can vouch for me here—the utilities we have to work with there are still very viewport-focused.
3. Content hierarchy. I often need to change an element’s priority, depending on the size of its container. Maybe I’ll conditionally position an element higher (or lower) to make it more (or less) visible, as the design warrants. In a flexbox-ier layout, I might want to change the order of a given element, or perhaps change the flex-direction of the module—and again, all based on the dimensions of the container.

Brad Frost makes a simple, logical argument:

… having a mechanism that says “if this component lives in a container that’s at least X-wide, make these style changes” feels like it makes sense.

It’s a smidge like responsive images. You can do a lot with srcset and sizes, but there is also <picture> when you need to be super explicit about how to behave.

Personally, I’d like to see about 100 different use cases fleshed out. If it turns out some of them can be done sans container queries, awesome, but it still seems highly likely to me that having container queries available to us would be mighty handy.