An Introduction to Container Queries

Photo by Venti Views on Unsplash

Container queries are a fresh and powerful feature in the world of web development. They allow us developers to create more flexible and responsive layouts. Unlike media queries, which apply styles based on the dimensions of the viewport, container queries enable us to apply styles based on the dimensions of an element’s container. This means that elements can adapt to the size of their container, resulting in more dynamic and intuitive designs. Since container queries are now officially supported in major browsers (Firefox added them in February), we can start using them to enhance our projects, and I’m incredibly excited about this opportunity.

In the front-end community at diconium, we’ve been longing for this feature ever since it appeared on our radar. Miriam Suzanne’s first proposal in 2015 came a long way and thanks to the R&D time we are granted, we had a glimpse into them.

One R&D initiative is the FE/UI Guild, a part of the Frontend Competence Center (presented in this article by my colleague Anastasia Dzamashvili). Every two weeks, an enthusiastic group of developers looks at the anticipated features, newly released CSS tools, and even well-established utilities for much-appreciated knowledge sharing and experimentation. Raphael Reich brought container queries to our community’s attention, so let’s have a look at them.

Let’s use the width queries

We’re quickly approaching a decade of anticipation for this feature. The two most important snippets of code that you need are the containment context declaration and the container query itself.

We use the container-type property and the value of inline-size with or without the accompanying container-name. The two can be combined in the shorthand syntax:

container: custom-name / inline-size;

Giving the container a name allows us to target it specifically in a query or skip it entirely so that we wouldn’t keep track of all the places a component is being used in:

.my-class p {
  line-height: 1.2;
}

@container custom-name (min-width: 72ch) {
  .my-class p {
    line-height: 1.5;
  }
}

Without the name, the query would apply the style based on the size of the nearest ancestor of the component with a containment context.

Container query units

To make the components more flexible, an array of container query units springs into action. As per mdn, here is the list:

• cqw: 1% of a query container’s width
• cqh: 1% of a query container’s height
• cqi: 1% of a query container’s inline size
• cqb: 1% of a query container’s block size
• cqmin: The smaller value of either cqi or cqb
• cqmax: The larger value of either cqi or cqb

We could for example adjust the font size or spacing of a text block based on how much space is available within its container, making it easier to read on different layouts.

Or we could change the position of an element based on the size of its container within the page.

It’s been so far slightly frustrating building components that could live anywhere on the page, changing layouts when things get too squishy, or the color depending on where it lives. Imagine a subscribe form that pops up in a modal, in comparison to it being shown in the header.

I’ve found myself in this situation countless times, reaching out for fluid layout techniques in the hopes of completing the much-needed design, and now we have this new tool at our disposal making layouts easily achievable.

One important advantage that comes out of this is re-usability. One component that can be used everywhere, as we now have full control over how it is displayed.

But this is only half of the story. The other half revolves around the UI designers themselves, giving new opportunities for designs better suited to their medium, and opening a Pandora’s box of new challenges to be tackled.

Photo by ines mills on Unsplash

There’s more to the container than meets the eye

Or better said, there’s more to it than meets the eye. The container-type property has two more interesting values. Size considers both the inline and block dimensions of the container, while normal will keep the container out of size queries, but still open for style ones.

Style queries aren’t here yet, but they’re just as special. These would allow us to better tune our components based on the visuals or custom properties of the parent. Style containers can be defined only by providing these with a name, while the query syntax wraps the request in style() as to differentiate it from size queries:

@container style(--property: true) and style(--accent-color: orange) {
  h2 {
    color: black;
  }
}

Let’s notice the use of the and operator here, giving us the wonderful opportunity to mix a variety of options. And since css custom properties can be handled from JavaScript, here’s another world of opportunities that is opening to us.

Photo by Timelab on Unsplash

CSS can do that

The recent additions to CSS have brought a wave of excitement and enthusiasm to the web development community, as we are now able to create more sophisticated layouts and designs with less code and greater ease. Container queries in particular give us a way for more intuitive and dynamic designs and as these new features continue to gain wider adoption and support, the future of CSS looks brighter than ever before.

I can’t contain my joy over all these features. Maybe browser support still boxes our code in a bit.