{"id":2174,"date":"2024-05-21T11:34:09","date_gmt":"2024-05-21T17:34:09","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=2174"},"modified":"2024-05-23T14:35:28","modified_gmt":"2024-05-23T20:35:28","slug":"weve-got-container-queries-now-but-are-we-actually-using-them","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/weve-got-container-queries-now-but-are-we-actually-using-them\/","title":{"rendered":"We’ve Got Container Queries Now, But Are We Actually Using Them?"},"content":{"rendered":"\n

When container queries didn’t yet exist and CSS developers were clamoring for them, developers went so far as to claim:<\/p>\n\n\n\n

\n

If we had container queries, most<\/em> of what we write as media queries today would actually be container queries. <\/p>\n<\/blockquote>\n\n\n\n

Like, on any given project, there would be more @container<\/code> in the CSS than @media<\/code>. I joined that refrain. I thought for sure it would be true, if not, more like 75%, especially considering how so many sites these days are created by composing sites through component libraries, and since components don’t know where they will be used, the CSS that style those components would use all<\/em> container queries.<\/p>\n\n\n\n

So, did this turn out to be true?<\/p>\n\n\n\n

Anecdotally: no, not really.<\/p>\n\n\n\n

Measuring usage<\/a> backs that up tenfold, but that’s not fair since container queries are so relatively new, no matter how developers feel about them or use them on new projects, container queries will lag behind media queries for a very long time. Certainly the biggest two reasons for any lag in usage are:<\/p>\n\n\n\n

    \n
  1. It’s new.<\/strong> It takes time for education about features to make it out to developers. Even when you know, old habits die hard.<\/li>\n\n\n\n
  2. Browser support<\/a> concern.<\/strong> The main one seems to be Safari 15, released as recently as 2022.<\/li>\n<\/ol>\n\n\n\n

    But even on new or actively developed projects where the developers know about them and the browser support choices enable usage (speaking from personal experience here, and it is polyfillable<\/a> for the record), it still feels like container queries aren’t reached for all that much. <\/p>\n\n\n\n

    Why?!<\/p>\n\n\n\n

    I have a few guesses:<\/p>\n\n\n\n

      \n
    1. Flexible layout methods that don’t need width\/inline-size based queries. The fact that with CSS grid we can use keywords like auto-fit<\/code> and auto-fill<\/code> to have an arbitrary number of columns<\/a> steals some of the need to specify columns at breakpoints. Also sometimes you can just… let stuff wrap.<\/li>\n\n\n\n
    2. Fluid type. There are a number of ways to pull off fluid type nowdays, and that site-wide typography scaling<\/a> really helps scale sites without needing breakpoints.<\/li>\n\n\n\n
    3. Components that tend to really benefit from styling updates at certain sizes are full-width anyway. Think of site header and footer elements that tend to be full width. For them, media and container queries are interchangeable.<\/li>\n<\/ol>\n\n\n\n

      It’s the within-container layout shifts that seem like the most useful and common use case to me. My most common go-to example is essentially this:<\/p>\n\n\n

      .card<\/span> {\n  container<\/span>: card \/ inline-size;\n}\n.card<\/span> .grid<\/span> {\n  display<\/span>: grid;\n  grid-template-columns<\/span>: 1<\/span>fr 2<\/span>fr;\n  gap<\/span>: 1rem<\/span>;\n  @container (inline-size < 300px) {\n    grid-template-columns<\/span>: 1<\/span>fr;\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      I’ve heard some interesting thoughts from others as well:<\/p>\n\n\n\n