{"id":375728,"date":"2022-12-13T05:53:56","date_gmt":"2022-12-13T13:53:56","guid":{"rendered":"https:\/\/css-tricks.com\/?p=375728"},"modified":"2022-12-13T05:53:57","modified_gmt":"2022-12-13T13:53:57","slug":"a-few-times-container-size-queries-would-have-helped-me-out","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/a-few-times-container-size-queries-would-have-helped-me-out\/","title":{"rendered":"A Few Times Container Size Queries Would Have Helped Me Out"},"content":{"rendered":"\n

CSS Container Queries are still gaining traction and many of us are getting our hands wet with them, even if it\u2019s for little experiments or whatnot. They\u2019ve got great, but not quite full, browser support<\/a> \u2014 enough to justify using them in some projects, but maybe not to the extent where we might be tempted to start replacing media queries<\/a> from past projects with shiny new container size queries.<\/p>\n\n\n\n

They sure are handy though! In fact, I\u2019ve already run into a few situations where I really wanted to reach for them but just couldn\u2019t overcome the support requirements. If I had been able to use them, this is how it would have looked in those situations.<\/p>\n\n\n\n\n\n\n\n

All of the following demos will be best viewed in Chrome or Safari at the time of this writing. Firefox plans to ship support<\/a> in Version 109.<\/p>\n\n\n

Case 1: Card grid<\/h3>\n\n\n

You kind of had to expect this one, right? It\u2019s such a common pattern that all of us seem to run into it at some point. But the fact is that container size queries would have been a huge time-saver for me with a better outcome had I been able to use them over standard media queries.<\/p>\n\n\n\n

Let\u2019s say you\u2019ve been tasked with building this card grid with the requirement that each card needs to keep it\u2019s 1:1 aspect ratio:<\/p>\n\n\n\n

\"A<\/figure>\n\n\n\n

It\u2019s tougher than it looks! The problem is that sizing a component\u2019s contents on the viewport\u2019s width leaves you at the mercy of how the component responds to the viewport \u2014 as well the way any other ancestor containers respond to it. If, for example, you want the font size of a card heading to reduce when the card hits a certain inline size there\u2019s no reliable way to do it.<\/p>\n\n\n\n

You could set the font size in vw<\/code> units, I suppose, but the component is still tied to the browser\u2019s viewport width. And that can cause problems when the card grid is used other in contexts that may not have the same breakpoints.<\/p>\n\n\n\n

In my real-world project, I landed on a JavaScript approach that would:<\/p>\n\n\n\n

    \n
  1. Listen for a resize event.<\/li>\n\n\n\n
  2. Calculate the width of each card.<\/li>\n\n\n\n
  3. Add an inline font size to each card based on its width.<\/li>\n\n\n\n
  4. Style everything inside using em<\/code> units.<\/li>\n<\/ol>\n\n\n\n

    Seems like a lot of work, right? But it is a stable solution to get the required scaling across different screen sizes in different contexts.<\/p>\n\n\n\n

    Container queries would have been so much better because they provide us with container query units<\/strong>, such as the cqw<\/code> unit. You probably already get it, but 1cqw<\/code> is equal to 1%<\/code> of a container\u2019s width. We also have the cqi<\/code> unit that\u2019s a measure of a container\u2019s inline width, and cqb<\/code> for a container\u2019s block width. So, if we have a card container that is 500px<\/code> wide, a 50cqw<\/code> value computes to 250px<\/code>.<\/p>\n\n\n\n

    If I had been able to use container queries in my card grid, I could have set up the .card<\/code> component as a container:<\/p>\n\n\n\n

    .card { \n  container: card \/ size;\n}<\/code><\/pre>\n\n\n\n
    Then I could have set an inner wrapper with padding<\/code> that scales at 10%<\/code> of the .card<\/code>‘s width using the cqw<\/code> unit:<\/p>\n\n\n\n
    .card__inner { \n  padding: 10cqw; \n} <\/code><\/pre>\n\n\n\n
    That\u2019s a nice way to scale the spacing between the card\u2019s edges and its contents consistently no matter where the card is used at any given viewport width. No media queries required!<\/p>\n\n\n\n
    Another idea? Use cqw<\/code> units for the font size of the inner contents, then apply padding in em<\/code> units:<\/p>\n\n\n\n
    .card__inner { \n  font-size: 5cqw; \n  padding: 2em;\n} <\/code><\/pre>\n\n\n\n
    5cqw<\/code> is an arbitrary value \u2014 just one that I settled on. That padding is still equal to 10cqw<\/code> since the em<\/code> unit is relative to the .card__inner<\/code> font size!<\/p>\n\n\n\n
    Did you catch that? The 2em<\/code> is relative to the 5cqw<\/code> font size that is set on the same container<\/em>. Containers work different than what we\u2019re used to, as em<\/code> units are relative to the same element\u2019s font-size value<\/code>. But what I quickly noticed is that container query units relate to the nearest parent that is also a container<\/em>.<\/p>\n\n\n\n
    For example, 5cqw<\/code> does not scale based on the .card<\/code> element\u2019s width in this example:<\/p>\n\n\n\n
    .card { \n  container: card \/ size; \n  container-name: card; \n  font-size: 5cqw; \n}<\/code><\/pre>\n\n\n\n
    Rather, it scales to whatever the nearest parent that\u2019s defined as a container. That\u2019s why I set up a .card__inner<\/code> wrapper.<\/p>\n\n\n\n