Comments on Container Queries: Once More Unto the Breach

27 Reader Comments

Back to the Article
  1. Ever since learning about Atomic design at AEA I’ve felt like this was an important missing piece in CSS. Glad someone is taking it on!

    Copy & paste the code below to embed this comment.
  2. A good concept, but wouldn’t this approach then make pseudo or state classes a bit of a mouthful?

    Copy & paste the code below to embed this comment.
  3. For some reason I have this strange desire to buy a hammer.

    Copy & paste the code below to embed this comment.
  4. @Mark and @Mat: If future CSS is capable of container queries and nesting (http://tabatkins.github.io/specs/css-nesting/) a pseudo-element could be written like so:

    .mod:media(min-width: 50em) {
      &::after {
         border: green;
      }
    }

    or even:

    .mod {
      &:media(min-width: 50em) {
        &::after {
           border: green;
        }
      }
    }

     

    Copy & paste the code below to embed this comment.
  5. The idea that a group of developers banded together and formed the RICG to tackle an issue they were dealing with is a really empowering idea!

    Now that the “I” stands for issues, does that mean we’ll see the RICG tackling more than one spec/problem at a time? How is it decided what problems are tackled next?

    Copy & paste the code below to embed this comment.
  6. Great article.

    @Ian, I was thinking almost the same thing.

    It would seem logical to me to nest the actual style rules inside the container query as you do with media queries:

    
    .mod:media( min-width: 320px ) {
         .mod-cost {
              float: left;
         }
         .mod-buy {
              float: right;
         }
         .buy-remaining {
              text-align: right;
         }
    }
    

    This would make parent-container—child-styles relationship very clear.

    Also, couldn’t a container behave in the same way as the viewport does, in terms of overflow?
    Afterall, isn’t the viewport just a container that can’t be affected by CSS? Element containers could behave in same way.

    It would be like each ‘module’ is similar to iframe. Each has it’s own viewport and so media queries are ‘localized’.
    Mockup: http://lab.gridlight-design.co.uk/containers/

     

    Copy & paste the code below to embed this comment.
  7. You could just use a framework like Zurb’s foundation or twitter bootstrap to do this without worrying about CSS and @media

    Copy & paste the code below to embed this comment.
  8. @andy “isn’t the viewport just a container that can’t be affected by CSS? Element containers could behave in same way.”

    I believe that’s the suggestion in the article. Nested viewports.

    Copy & paste the code below to embed this comment.
  9. @Jake - sure, just trying to clarify :)

    Also to make the point that it would make more sense if the syntax followed the pattern of ‘normal’ media query. Viewpoints don’t have pseudo elements and have a set way of dealing with overflow.
    Those were some of the issues that came up (above) but are non-issues if the browser handled element-based containers in the same way as viewports.
    Wouldn’t that make it easier to implement?

    Just my 2p :)
    Cheers

    Copy & paste the code below to embed this comment.
  10. Would it be too ridiculous to allow element queries with the caveat that the CSS modifying any attributes specified in the query is ignored?

    Copy & paste the code below to embed this comment.
  11. I don’t get it, it’s just as easy to create an infinite loop in JavaScript, but that didn’t stop browsers from supporting it. Write good code and you won’t have that problem.

    This is what I’ve been using to accomplish element media queries: https://github.com/coreyworrell/responsive-elements

    Copy & paste the code below to embed this comment.
  12. I’d love to see something like this make it into the CSS spec. I came up with a simple little JS approach I’ve been using in the mean time: https://boagworld.com/design/context-queries/

    Copy & paste the code below to embed this comment.
  13. It’s a nice addition to CSS. Simple, self contained, grouped.

    And anyway, infinite loops exists in all programming languages since the beggining of time, we already know how to avoid them :-]

    Copy & paste the code below to embed this comment.
  14. While I agree that infinite loops have been a danger forever, I’d argue that it’s much more difficult to reason about CSS-style infinite loops. In procedural languages, you’ve got only a few ways to create infinite loops:

    while (true) { // code that will run forever }

    and

    function doSomething() {
      doSomething();
    }

    CSS element queries as discussed would have similar problems, and generally they’d be easy to reason about, like in this example:

    .sidebar:media(width: 500px) {
      width: 499px;
    }

    That’s an obvious and trivial case. But what about this?

    .sidebar {
      float: left;
    }
    
    .sidebar-header {
      width: 500px;
    }
    
    .sidebar:media(min-width: 450px) > .sidebar-header {
      width: 400px;
    }

    Floated elements always take on the size of their content. The header is 500px wide, which means the sidebar will be too. But as soon as that sidebar is 500px wide it matches the element query, which resizes the header down to 400px wide, thus making the sidebar shrink and no longer match the element query. At which point the header grows to 500px again…

    (Example taken from Tab Atkins’ awesome article on element queries.)

    It’s these non-obvious loops that make the RICG and the browser vendors very wary about element queries. As Mat says, redefining the solution as ‘container queries’ lets us think about the issue differently.

    Fake viewports (á la iframes) have been suggested (NB: I think the implementation would permit pseudo-elements on these containers because they wouldn’t be a viewport; they’d just have a viewport). The article also suggests an implicit overflow: auto on elements with container queries.

    (Although I’d really like to see the pseudo-class called :query() rather than :media(), because it’s not really about the user agent’s media anymore. It’s about individual elements.)

    Copy & paste the code below to embed this comment.
  15. I thought a lot about “element queries” over the past year and I’m happy to see that you have arrived to my same conclusion: container/context queries.

    This is my personal solution/trick/polyfill: https://github.com/molocLab/context-queries.

    Syntax is different,but the concept is the same.

    Copy & paste the code below to embed this comment.
  16. This sounds weird (and it is) but perhaps instead of an implicit overflow behavior on container elements, the query property would be implicitly applied to the child?

    For example:

    .parent:media(min-width: 500px) .child {
     width: 499px;
    }

    Would essentially become:

    .parent:media(min-width: 500px) .child {
     width: 499px;
     min-width:500px; /*implicit*/
    }
    Copy & paste the code below to embed this comment.
  17. The problem is very real! I think it’s wonderful that there are sharp minds working together to finesse an elegant (and hopefully stable) solution.
    Very interested to see where this goes.

    Copy & paste the code below to embed this comment.
  18. This may be very useful for HTML Elements (polymer) or Components that a “reusable” (React). Think of a component that can be dropped anywhere into a page and depending of size available for this component it can style itself to fit and look best.

    Awesome article.

    Copy & paste the code below to embed this comment.
  19. Just thinking out loud here:
    Since the CSS 4 has selector can be used like a parent selector - could that cause problems in combination with the container queries?

    Copy & paste the code below to embed this comment.
  20. We have been always experiencing problems with the print media queries. Thanks a million for the post. It helps us a lot. You can see our work in https://www.wishingwell.es/ Hope you like it. We keep in touch.

    Copy & paste the code below to embed this comment.
  21. Hey All,

    I was wondering what is wrong with doing it like this in the document header:

    —-
        <link rel=“stylesheet” media=”(max-width:480px)” href=“mobile.css”>
        <link rel=“stylesheet” media=”(max-width:720px)” href=“tablet.css”>
        <link rel=“stylesheet” media=”(min-width:721px)” href=“desktop.css”>
    —-

    Seems simple enough, without new syntax or javascript?

    Copy & paste the code below to embed this comment.
  22. Copy & paste the code below to embed this comment.
  23. @Rene van der Lende
    There’s nothing wrong per se, but it could lead to lots of code duplication. Imagine a website with 4 major breakpoints and a module, that does switch between a horizontal and a vertical styling: vert -> hor -> vert -> hor. One of those two options could be the default styling, but the other styling would be duplicated in e.g. tablet.css and xlarge.css. Also the notion of switching the whole site’s styles on a single breakpoint is quite inflexible in itself.

    Copy & paste the code below to embed this comment.
  24. I came up with a proposal for container queries which tries to solve the recursion issue: au.si/css-container-queries
    The idea behind it is to let the browser select the “right” container for the container query.

    I also created a prolyfill which implements this proposal:
    github.com/ausi/cq-prolyfill

    Copy & paste the code below to embed this comment.
  25. this is great article ,This may be very useful for HTML Elements (polymer) or Components that a “reusable” Harga Ban Forklift Bridgestune.

    Copy & paste the code below to embed this comment.