Open matthew-dean opened 6 years ago
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!)
@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?)
@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.
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: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).