Container queries are here!

General Web Design
1

So, Apple has been shipping out Safari 16 (last night it updated on my mac) on both desktop and ios, and Chrome 105 on both desktop and android is supporting container queries. Which means that this long-awaited revolution in how we can build sites is here, now, in the mainstream (at least for users whose devices auto-update, not those stuck in corporate IT hell while their organisations carry on debating whether to go with Mosaic or Spyglass). There is also a slew of other exciting stuff in the new browser updates (including :has(:target) and subgrid).

If you want a glimpse of what container queries will do, take a look at this pen from Ahmad Shadeed, who has also written about the subject.

https://codepen.io/shadeed/pen/ExZEEjZ?editors=0100

If you look at it first in a browser, like Firefox or Opera, which doesn’t yet support this standard, you’ll see that as you drag the card out from the corner it behaves exactly as we’ve come to expect web elements to behave. But look at it in the new Safari or Chrome, and you will see how the card transforms from small image above text to medium image alongside text to full screen banner with text overlay. Of course, we’ve been able to do this for some time with media queries and breakpoints, but only for larger or smaller devices.

The beauty of this new approach is that we can take a component we have created and it will configure itself according to the size of the space we drop it into. (Think of a blog, for instance, where the newest item automatically fills the whole screen width, but then becomes one of a group of medium sized cards when a new item is added, and then eventually gets shunted into a list of small items.) Design systems like the BBC’s and Guardian’s now become possible to us.

The difference between the new browsers and the old also shows that the design will degrade gracefully on older browsers — they may not give the same effect, but they won’t lose or garble anything (and if we use @supports we can create still elegant designs for older browsers).

1 Like
2

The issue though, remains that many will not be able to take advantage of Container queries and see how the web designer expects their page to behave.

E.g. I have the latest Safari and Chrome and can’t see the intended result.

Careful use of container quesries will beneeded to provide a fall back for those who will never be able to use a browser that supports container queries.

The isssue for designer wil be how they can accurately check their layouts. I don’t believe such an App based testing solution exists.

We do have alternative solutions today, such as the BBC layout that work on all browsers, but they are not as easy to implement as container queries.

It’s a big shame really that could be rectified by a relatively small amount of effort from the browser developers - looking at you Apple.

3

The demo is working beautifully on yesterday’s Safari 16 and Chrome 105.0.5195.125 (although Chrome 106 will provide full compatibility for container queries) — Safari Technology Preview and Chrome Canary have been able to do so for yonks. And the most striking thing about it is that its behaviour on non-compatible browsers would really be fine in most situations (there are also some straightforward workarounds: for instance using % as a fallback for the cool new cqw unit in many circumstances).

Backwards compatibility is always a thorny issue, not least because corporate IT dictators keep their subjects in Windows NT Hell, or its equivalents. These days, though, the disconnect between the clunky operating system people have on their desks and the powerful modern devices they have in their pockets is striking. (And there is a certain irony that sites that are firewalled out of workplace networks can simply be accessed on the phone). The tech companies seem to have no qualms about orphaning users once their devices get to about 6 years old, and that would seem to be a reasonable amount of backwards compatibility for most purposes. (My old iPhone 6+ can’t use most new third party apps and any of Apple’s new stuff — I get the message, it’s more than time to upgrade.)

4

I would say it is a potential showstopper if your browser doesn’t support a feature like Container Queries AND the developer did not design fully for this event.

Fully testing for these browsers that are the very latest is not easy and requires an additional non upgraded test system older than 1 day (today).

Also, I am not sure that RW users are ready to deal with another type of media query. From an implementation viewpoint, Source has screen with media queries, cleverly built into every stack, and addition multiple BP functions. Adding a container query would also need this level of integration adding additional Edit mode processing delay and complexity.

It’s probably going to remain a user coded function for RW users.

5

Good points, but change happens. I see big potential for the changes in this current round of browser developments. And it’s probably not going to remain a user coded function for RW users because, even if nobody else does so, I’m going to make stacks for it (in fact, my very first stack, which I’m trying to wrap up now, supports container units with a fallback).

6

Here’s a quick test I put together — two versions of the same page, both with the same ‘container’ version, the first without a fallback and the second with an ‘@supports not (container-type: inline-size)’. If you try looking first with Safari 16 or Chrome, and then with a browser that doesn’t yet support container queries, like Firefox, the difference should be clear.

https://shakennotstirred.net/container_test (no fallback)
https://shakennotstirred.net/container_fallback/ (with fallback)

The ‘container’ version shows the beauty of container queries. This is the same element dropped into three containers (all Grid Plus Pro items in a Source grid, with a class specifying ‘container-type: inline-size’ assigned to each — that really is all it takes to make something a container). The element is specified using cqw — container query width units — both the type size and its positioning. These units (cqw and cqh) are the equivalents of the media query vw and vh units, only they are 1/100 of the width of the container they are in, rather than the viewport. This means that elements scale precisely — everything remains in the same relative position — if they are put into larger or smaller containers. If containers themselves scale with the viewport, the elements in them thus also become responsive.

The fallback is pretty straightforward, but inevitably the elements in the three grid items have to have their positioning and type size specified independently (I seem to always have difficulty getting Source Grid’s flexbox controls to centre something vertically in a grid item, otherwise the only thing the element would require would be the type size). You might argue that there is not much point using container queries when we have to also specify elements as before, but the simplicity of having elements automatically resize (and the cleverness of getting them to automatically reconfigure) makes the container paradigm simply amazing. And at some point we’ll be able to ditch the fallbacks.

7

I think this is a good demo and assume I see what you see. (Only my latest Chrome on Mac supports container queries).

That’s what I was getting at. You also potentiall need the same query support for all the content, making the interface more complex. Maybe Stacks 5 can remove some of the RW shackles and allow for a more elegant solution in the future.

I do really like the idea of using cqw value for using in Calc values for scaling text, number of visible lines, etc…

You may be setting the vert centering further up the chain in the grid or inserting someting like a Container or Coder stack which would become the ‘container’. Perhaps try adding the Utillity Stack alignment classes.

5-10 years for an estimated full support judging by the current strategy being adopted/forced/crippled/purged by Apple, Chrome, etc…

IMHO there is a huge gap between the pathalogical updaters who crave the latest versions living under the spectre of the security boogie man vsiting them, versus the average user who ignores any reminder to update or upgrade, and plods along with their perfectly functioning system until it breaks down.

BTW, I’m completely behind container queries and blown away with what can be done with them, but the adoption of browser support and the additional work needed to provide a fallback and the tools to test for all cases, are currently making container queries an overly complex and time consumiing solution.

I hope I am wrong about this complexity and must find some time to get some real experience of them.

Also it will be very interesting to see if and how any of the main traditional frameworks like Bootstrap, will adopt support, as that won’t be easy going forward.

8

The beginning of this first video is a useful (if chalenging to watch:) )demo of what container queries do well, for anyone looking for more info.

9

With iOS 16, those kinds of updates are separated from the OS updates.

Same for Windows (on Edge and Chrome).

Let’s hope Ventura does something similar (to be honest I haven’t kept up so it might).

Cheers,
Erwin

10

After some thought, I think that I have been over complicating the fall back configuration in a CSS grid.

Source CSS Grid is the main and I reckon, only place that Container Queries may be needed to implement some pretty sophisticated layouts like the BBC Home page layout. If you are not using Sources clever grids then I don’t really see any good application for Container Queries.

I the interests of considering how this could be implemented in Stacks, here is how it might work:

The use of Container Queries only makes sense when a CSS Grid is configured in a layout that suits Container Queries. I.e. multiple different grid positions that have multiple rows and colums that reconfigure in size depending on the browser width - think BBC Home page layout.

Therefore, that layout configuration needs to be triggered by a single Use Container Queries checkbox in either the Source Grid Plus or Grid Plus Pro stacks. If checked, this new checkbox would check for @support, and IF the browser has support, then use Container width instead of viewport (screen) width for all breakpoints.

Doing it this way, would allow 2 different grid layouts to be built, depending on the browser’s Container Queries support. That alone should provide enough fallback and the Container Queries supported version would then only need a simple code solution to do something such as align content inline or stacked targeted at specific grid positions - as we currently do.

E.g. So with a Container Queries supported browser, a blog, product or news layout could reduce the size (width and height) as you go further into the grid and also redice and reconfigure the sixe, type and length of text as you go further into the grid. The benefit being that you can get more posts, products or news items onto a page. The non Container Queries supported browser could display mostly equal sized items with the same content type size and length in each grid - as we do today with Source + Poster.

Taking this idea further, another way might be to select to use Container Queries throughout a whole page by building the whole page inside a simple grid or, or inside a Coder or Container, where they become the container which will track the viewport width. If there is no browser support, normal viewport queries could be used.

This is all just thinking out loud really about how to implement a fullproof fallback.

11

FYI the reported Can I Use figure of 42% is I think, somewhat over optimistic.

The 42% comes from Chrome on Android and really the effect of implementing Container Media Queries (CMQ) is put to best effect on desktop sized displays so it woudl be reasonable to argue that mobile support usage is not as relevant. Also that support is not full support according to Can I Use.

Today, MacOs support is just 0.001% and Safari 16 is the only browser to fully support CMQ. Safari v16 is currently only days old, but to put Safari in perspective, only 3.28% of browsers are Safari for ALL versions below 16. So even if Apple updated (they won’t) all versions of Safari to provide CMQ support, it would only currently be 3.28%.

It’s the same thing for Container Query Units.

I am surprised and dissapointed that the browser support is so low.

12

Thankfully, things happen a lot faster today than previously. CSS grid took nearly 10 years to be implemented. I do however think that patience is prudent. There have been JS polyfills for a long time but, just like doubling up CSS with fallbacks, I tend to think that from a technical perspective, it is better to wait for native implementation.

1 Like
13

Gary, you’re right that the implementation of container queries is really quite simple. The parent container just needs a container-type declaration, and there needs to be some kind of fallback for the cq units. For my first foray into stackmaking I’ve got a few lines of vanilla Javascript which finds out the width and height of the parent element and save it as a css variable. In a stack template it’s then pretty simple to divide that that variable by 100 to get a cq unit equivalent and then multiply the result by the size the user has set for the element in the container (such as the font size). I’m not sure how one would do this outside of Stacks, but then my understanding and capabilities here are very limited. Still, the fact that someone like me with very limited abilities in coding could even do this suggest it’s not, in the scheme of things, very difficult.

I’m tempted to make myself a hack of Grid Plus Pro to implement container queries and the other thing I’d love for Stuart to add to it, grid-template-areas — it would be a good exercise to develop my fledgling abilities.

14

I have grid-template-areas added in a branched version of Grid Plus Pro. I can take a look at pulling that into the release version if there is demand for it. This though is literally the first request i have seen for it. I personally don’t see many benefits for using the areas method but appreciate that it may better suit some people’s approaches to grid building.

As for container queries - they will definitely get added as an option to my stacks (where relevant to do so) but I agree with @tav - we are still a bit away in terms of the required levels of native browser support.

15

Stuart, that’s great news about grid-template-areas. And where they really come into its own is with container queries — for instance, if you want to reconfigure a card so that in a smaller size the image is moved alongside instead of above and a long explanation is dropped in favour of a one-liner… that becomes easy if we have defined template areas and are then re-arranging, adding and dropping them at different sizes. (Also, I’d add here that container queries get around one of my bugbears — what happens when three columns goes to three, or three to two. Because if we are scaling type responsively, we can end up at breakpoints with bigger cards and smaller type, which is horrible.)

I’m not sure what the issue with ‘native browser support’ is, though. Safari 16 fully supports container queries, and we can reasonably expect the other webkit browsers to follow, and so does Chrome 106 (although 105 supports most aspects already and, importantly, container units). And the web is not a one-size-fits-all place any more — if one’s audience is kids who upgrade their phones every year, expectations of users is very different from sites whose audiences are locked behind corporate firewalls. Really, we’re now in a world split between those whose devices are set to auto-upgrade, and those who are still expecting their ten-year-old legacy operating systems to deliver for them. Unless one is the BBC, or some other organisation which has to be there for everyone, we really don’t have to wait for the laggards to catch up (app developers don’t). 42% of billions of people is still billions of people, and often now contains whole audiences.

16

But that is 42% of Android mobile users on which the effects of a beautiful container media restructure will not be visible due to the small screen size.

Unfortunately, it’s still only 0.001% of Mac users.

E.g. I can’t upgrade to Safari 16 on my Mac because it is too old but is blistering fast and does everything I want. I don’t want my phone to upgrade to ios 16 and my iPad will stop itself from upgrading and I have no intention of jumping through all the Apple hoops to create enought memory in my 16Gb memory to make space to upgrade it. None of my Mac owning friends or family have upgraded beyond the MacOS that their Mac was delivered with.

It’s a pity but we are still too early in terms of years I suspect.

17

I’ve got the latest versions (non-beta with default flags) of various browsers on my computer and in my 3 main browsers: Brave, Safari and Firefox (including Developer Edition) container queries aren’t supported natively. It’s coming but its not here yet.

p.s. if you want to test out the grid template areas option in Grid Plus Pro let me know and i can pass on a draft version.

18

Stuart, Safari 16 is supporting container queries — do you have it yet? I was surprised when Gary said he wasn’t seeing anything in Safari either as Apple auto-updated my desktop Safari to 16 last week, and the iOS version has been rolling out for more than a week too. Anyway, the new ‘normal’ versions of Safari and Chrome (and not just ‘Safari Technology Preview’ and ‘Chrome Canary’) are showing my container test, as is Microsoft Edge (which I wasn’t expecting); Firefox and Opera, not yet.

19

And yes please to Grid Plus Pro template areas edition! ;-)

20

Correction, latest version of Opera is working with my container queries demo — after updating and clearing the cache. So Safari, Chrome, Edge and Opera… yes! Firefox and Brave, no.