Use case: Responsive Grid Systems

[matthew-dean]

On our app, in order to efficiently scale a design from 320px to 1920px, our designers early on came up with a system of tiles. Meaning: many of the layouts had tiles that would "contain" content, such as media and type, and what would change at different breakpoints was the number of tiles for that viewport.

That way, the tiles were mostly of uniform sizes even as the viewport would grow, and the number of differing designs is limited.

However, inevitably, the dimensions of tiles is not a constant, and we originally tried to use @media queries to capture these differences, but that was a fool's errand because:

1. In general terms, we had a grid that was 1 column at "mobile", 2 columns at "tablet", 3 columns at "desktop" and 4 columns at "HD". At the larger sizes, the container snapped to a fixed width, but at smaller sizes, the container would flex to the size of the viewport.
2. At each of those sizes, we had tiles that would span either multiple columns or multiple rows or both. So each breakpoint had column-spanning and row-spanning variants, meaning, inevitably:
3. "Smaller" viewport sizes had some tiles that were larger than "larger" viewport tiles, and some breakpoints might have tiles that were both larger and smaller than other breakpoint tiles depending upon just where in the breakpoint "range" the viewport happened to be.

In short:
Solving this problem with @media queries is next to impossible. The number of variables involved multiplies the complexity exponentially. However, solving this problem with container queries is extremely trivial. You target the available space, and layout the contents of a tile accordingly.

A final note:
Probably a large culprit of why this design has come about in the first place is, ironically, the CSS Grid spec. It's now really fairly trivial to create layout grid variants at different breakpoints, with different row and column spans. However, this has made responsiveness and even more difficult challenge. Because when you can easily create so many sizing variants for content blocks, how do you create rules for that content?

Another culprit is probably component-focused design systems pushed by libraries like React and Vue. Modern web dev is often very component-driven, with a focus on composing components together into larger components. Neither of those have anything to do with the viewport, so styling based on viewport dimensions becomes more of a challenge than design methodologies of the past (even though component-focused design carries many advantages).

[beep]

Okay, this is great. Matthew, the tile system you’ve described sounds like a perfect use case. It describes the problem perfectly, and overlaps nicely with something I’m (finally) writing up.

I’d like to see if we could write this up. @matthew-dean: Would you be willing to draft a use case based on this, perhaps with a diagram or two showing a generic version of the design you had to implement?

(Apologies for missing this when you first opened it; I appreciate you nudging us in Slack!)

[matthew-dean]

@beep Can you explain more of what you need besides what I already wrote? Isn't this already a use case? (I guess just the diagram you're looking for?)

[beep]

@matthew-dean Hey, of course. And great question, thank you!

I’d suggest taking your text above—which is very good—and turning it into a generic-sounding example. Less “this is a thing I worked on”, and more “here is an example of the problem that container queries would solve.” If some rough layout diagrams would help (and I think it might? possibly?), please feel free to include them.

Does that help clarify things at all? If you haven’t seen it already, take a look at the current use cases document. That might provide a little bit of direction. And of course, if you’d like some help, please don’t hesitate to ask here or in Slack.