Many of you will now have the latest Safari (16) — I downloaded mine early yesterday morning. And with it comes a whole slew of newly supported features that are going to make webbuilding even more powerful and exciting. One that has been long awaited is container queries.
If you haven‘t heard of container queries, think about media queries, but applied to objects instead of screen sizes. With media queries we have breakpoints where things can change size and configuration according to the width of the screen (‘viewport‘). And they come with two units, vw (viewport width, one unit being 1/100 of the screen width) and vh (viewport height, one unit being 1/000 of the screen height), which allow us to make our designs responsive. For instance, if we specify font-size in vw, rather than px or rem, type scales automatically according to the width of the screen. They‘ve been an amazing part, if underused, of the web of the last few years.
Container queries are similar, but depend on the width of the parent element instead of the screen width. They also come with their own units, cqw (container width, one unit being 1/100 of the parent element width) and cqh (container height, one unit being 1/100 of the parent element width). So what‘s the big deal about this? Well, imagine you‘ve created an element — a card, for instance — that is specified with container units. Drop it in to a wide container — a wide layout column, for instance — and it will automatically scale to fit. Ditto, dropping it into a small column. With container queries elements resize according to where they are placed. This makes it possible to have a library of pre-built components which we can copy and paste into our layouts, without having to adjust anything.
I made these two simple demos of containers as an example. In the first, the word appears at the correct size on a browser which supports container queries (like the new Safari and Chrome) but they are tiny on a browser that currently doesn‘t (like Firefox). In the second demo I‘ve created a fallback with @supports for browsers that don‘t support container queries (it‘s not so difficult to do, but it means that each element has to be treated separately).
https://shakennotstirred.net/container_test
https://shakennotstirred.net/container_fallback
But it gets better than this. Much better. Because just as media queries allow us to change the arrangement of elements, as well as their sizes, at a breakpoint (for instance, stacking columns vertically on mobile), so do container queries. But container queries do it without the screen size changing. Imagine a blog. The latest post has a banner that fills the whole screen width, with title and description over the image. The next few previous posts have a card, image above text, with perhaps four cards in a row. Even earlier posts are in a list, with miniature cards, small thumbnail alongside small text. You‘re sure to have seen this kind of approach on news and other sites.
With container queries, the full width ‘hero‘ banner, the big card, and the tiny one are just the same element at different container breakpoints. Drop a new post into the layout, and it automatically becomes the new banner. The old banner drops down to become the first big card, and the last big card gets shunted into the small list. All sorts of possibilities open up at this point.
This is a nice demo which illustrates this (in a container capable browser), by Ahmad Shadeed, who has also written about the subject.