That Paul Robert Lloyd has written up a lovely, persuasively-argued response to my post on container queries. In his post, he questions the need for container queries, and suggests they might very well be obsolete. It’s a great post, and one I’d strongly recommend reading in full. But! Let me quote the three prongs of his argument here:

…here are three reasons why I’m not sold on the need for container queries:

  1. While no longer canvas-in, they still provide an inwards approach when we should be designing from the content out.
  2. New CSS layout primitives give us tremendous power to make component-level layout adjustments already. We should build on existing specifications and concepts rather than define new ones.
  3. Often, when components are resized, they need to change their behaviour as well as their presentation; container queries would not help us in that respect, so perhaps other tools are better suited to this job.

The third point — about viewport-specific behavior — I don’t disagree with, but I don’t know that necessarily invalidates my argument. I would, however, like to respond to his first two points, as I think Paul’s partially correct — but I think our need for container queries still stands.

Paul’s really done me a kindness, here: he’s touched upon a loose chink in my argument, and given me a chance to strengthen it a bit. Specifically, he notes that the example I used in my post on container queries — a module that grows from one-column up to three, until it moves into the sidebar, at which point it reverts to a 2-column layout — could easily be created with a little flexbox magic, without needing media queries, much less container queries. And he’s right! Flexbox would mitigate the need for all that float/nth-child() work I’m currently doing; heck, Grid Layout would probably obviate the need for all that JavaScript I’m using to change the module’s physical position.

In other words, these new CSS layout tools give us considerable control over how our patterns adapt, all based on the size of the amount of space allocated to them. And as Paul notes, the example I used would be an excellent candidate for using those new layout tools, and container queries wouldn’t be needed.

However. However! Column management and reflow aren’t the only layout considerations I need to make based on the size of the container. They’re not even the only design considerations I need to make. 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.

These are all design hurdles I have to clear on a near-daily basis, and I definitely should’ve mentioned a few of them in my original post. And as far as I know, the new layout modules Paul mentions won’t help me solve these problems. While I can currently make these changes with media queries and a bit o’ JavaScript, this doesn’t feel sustainable. In other words, I’d still love to use container queries to more elegantly and effectively work through these issues — and I think you might, too.

There’s one other point of Paul’s I’m still wrestling with: namely, that container queries would reinforce a “canvas-in” approach to design, where we should, as Mark Boulton argued, be looking for more opportunities to design from the content out.

I can see Paul’s concern, and I share it. I can absolutely see the risks in using container queries to potentially fragment our designs further, creating pages filled with a host of tiny, disconnected designs. But I also wonder if it’s a little…premature, potentially. Speaking for myself, practice-wise, I’m at the very beginning of learning how best to design responsively. I’m still unlearning many of those old, page-focused design practices I grew up with — and maybe you are, too.

But it’s also possible that we will, in time, learn to use container queries more effectively, and create more device-agnostic, content-focused designs. Designs stitched together from connected patterns, which feel at home on any screen they appear on. (Or no screen at all.)

I could be wrong, of course. But before we can criticize the approach, I think we’d need a working container query implementation to find out where our methods fall short. And I don’t know about you, but I still feel strongly that container queries are needed — and if you agree, maybe you could help us figure out how to make them happen.