Thoughts on Container Queries

cq.css

/* 
  This is not meant to be a final CSSWG proposal, 
  but reflects my immediate thoughts after reading
  [David Baron's](https://github.com/dbaron/container-queries-implementability) promising draft.
  This gist was created to demonstrate my idea for removing selectors from his query syntax.

  More of my thoughts & notes are online at css.oddbird.net/rwd/
*/

main,
aside {
  /* PROPOSAL: contain:size creates an implicit "container root" or "containment context" */
  contain: size;
}

/* our modular object that requires container queries */
.media-object {
  display: grid;
  gap: 1em;
}

/* The dbarron proposal makes you select a root explicitly  */
@container main (max-width: 45em) {
  /* media-objects only inside main, but not aside */
  .media-object {
    grid-template: 'img content' auto / auto 1fr;
  }
}

/* PROPOSAL: The goal is *modularity*, so we want this to work in any context */
/* I'm suggesting that this syntax should work without a selector, */
/* inside any *implicit* "containment context" - the nearest ancestor with size containment */
/* (For the purpose of this step, the viewport should be considered an outer-most containment context) */
@container (max-width: 45em) {
  /* media-objects inside main or aside, or any other "contained" element */
  .media-object {
    grid-template: 'img content' auto / auto 1fr;
  }
}

/* ❌ I was tempted to merge this into @media - */
/* but after some consideration I think this is more confusing than helpful. */
@media screen and container(max-width: 45em) and (orientation:portrait) { ... }

I can maybe see use-cases for the explicit container-selecting syntax, but not as many. Maybe for checking a container that is not the nearest containing ancestor? If you only want the CQ to apply in a specific context, that can already be done with selectors inside the CQ.

There would also be something tempting to me about following the @supports selector() {} approach, rather than creating a new at-rule.

/* a function-based approach */
@media context(max-width: 45em) { ... }

/* or */

/* a keyword-based approach, maybe with a default/implicit "viewport" option */
@media container (max-width: 45em) { ... }

I haven't thought through all the implications there yet. Could you mix CQs with other media queries? Is that useful?

@mirisuzanne I haven't thought through the implications either, but I wonder about this syntax since it allows us to keep the benefits we already have with media queries.

@media screen and (max-width: 45em) and (container: viewport|container) { ... }

+1 to @mirisuzanne's proposal.

This will be prototyped in Chromium as per https://groups.google.com/a/chromium.org/g/blink-dev/c/u1AKdrXhPGI/m/wrJb-unhAgAJ?pli=1

The plan for the prototype is to use Miriam's proposed alternative, i.e. containers will be marked with "contain: size", and a new at-rule "@container (min-width: 100px) { ... }" specifies the rules that apply given the size of the container. This is not at all finalized, but the underlying problems we need to solve in Blink are (mostly) the same regardless of how the feature is accessed, so we'll for now use this proposal as the temporary syntax.

Chrome Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1145970

Looks fantastic, @mirisuzanne

Cosign. This is really, really exciting to see, @mirisuzanne.

Thanks, y'all - still very much in progress, but glad you like the direction. I added a section about building on @media syntax, which I think would be another improvement. I'm not convinced that this is an entirely new concept requiring entirely new at-rules. We already have the viewport as a default "containing context" for media-queries, and we're simply adding the ability to define & respond-to nested contexts.

Really really excited for this direction! I was pulling for implicit container queries as they are more useful when you have smaller components and you need them to respond to an unknown container. This also seems to simplify the logic as to what container an element responds to as it is nested.

@scottkellum, @beep, @scottjehl: we're looking for partners to trial these new features with. It would need to be a production site, ideally big enough to really hit edge cases. Would any of you like to sign up? Keep in mind "intent to prototype" really means run some experiments and figure out what's missing and then add that! Want to be involved?

@stubbornella I would absolutely love to help out here! I should have some time next week to stress test this. I am not working on any large scale production sites right now but I’m happy to put it on a medium scale site and put it through its paces in a number of tests.

@stubbornella I’m here to help however I can, absolutely. That said, I’m in a similar position as @scottkellum: I’m not working on any large-scale sites at the moment. But I’d be thrilled to work with this on whatever edge case-friendly sites I can offer.

@beep @scottkellum - I need at least a few big sites with A/B test infrastructure, but smaller sites are great too! I'd love to have you put it through it's paces during the origin trial (experiment). We'll have signups when the prototype gets near completion in 2021.

In this demo https://tobireif.com/demos/grid/ I use this element queries syntax and lib https://github.com/eqcss/eqcss/ by @tomhodgins .
In the source of my demo https://tobireif.com/demos/grid/view_demo_source/ you can see that I use the "ew" (element width) unit specified at https://github.com/eqcss/eqcss/ . An example:

@element .heading and (min-width: 277px) {
  h1 {
    font-size: calc(3.0ew + 110px);
  }
}

This unit is quite useful.

Does the current proposal offer such a unit?

This gist was a very early draft.

• There is a more fleshed out proposal: https://github.com/oddbird/css-sandbox/blob/main/src/rwd/query/explainer.md
• And a CSS Working Group project board: https://github.com/w3c/csswg-drafts/projects/18

Units weren't in the initial proposal, but they've already been approved by the CSSWG to be part of the spec (w3c/csswg-drafts#5888) once we figure out what to call them.

Thanks for the info @mirisuzanne !