After all these years of using CSS Grid and I still feel like I haven’t grokked everything that it’s capable of. Ahmad Shadeed’s latest interactive tutorial is a great reminder of that where he’s written about named grid areas and explains the following bit of CSS:
.layout {
grid-template-columns: [full-start] 1fr
[content-start] 2fr
[content-end] 1fr [full-end];
}
So what Ahmad has done here is defined and named specific areas of a grid and then he can use them elsewhere in his CSS like this:
.layout-item {
grid-column: content-start / content-end;
}
Smart stuff.
Miriam Suzanne:
There’s no rush to rip out all your media queries, and replace them with containers. You’ll be fine waiting for widely available support and your next scheduled re-factor.
But if you’re still avoiding grid – whatever your reasons – you are, in fact, missing out. CSS grid is one of the best features in CSS, and one of the biggest time-savers on every site we build.
One part of Grid that I’ve been ignoring for too long is the whole template areas syntax...
.grid {
display: grid;
grid-template-areas:
"head head"
"nav main"
". foot";
}
.grid header {
grid-area: head;
}
For some reason it doesn’t feel grid-y enough for me but I should just sit down and try to get used to it. Even looking at it now I’m slowly realizing that it’s real nice that you can use . to denote an empty column which makes things quite a bit easier. Oh and this reminds me, the other day I spotted this CSS Grid Template Builder by Anthony Dugois and it’s pretty handy!
Rachel Andrew:
The Chrome team believes that masonry should be a separate layout method, defined using display: masonry (or another keyword should a better name be decided upon). Later in this post, you can see some examples of what that could look like in code.
There are two related reasons why we feel that masonry is better defined outside of grid layout—the potential of layout performance issues, and the fact that both masonry and grid have features that make sense in one layout method but not the other.
The most compelling argument for me is the potentially very confusing overlaps and underlaps between grid and masonry where sometimes a grid property just won’t apply to a masonry-style layout. However, this example that Rachel shares in her post certainly feels icky to me:
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, auto);
}
.placed {
masonry-track: 2 / 5;
}
At a quick glance, and without understanding too closely what’s going on under the hood, I’d question why the heck this looks so much like a grid-but-not-a-grid syntax. Maybe I just gotta sit with it some more though!
Cool cool cool:
Too often have I witnessed the improvising musician sweaty-handedly attempting to pinch-zoom an A4 pdf on a tiny mobile screen at the climax of a gig. We need fluid and responsive music rendering for the web!
Music notation should be as accessible and as fluid as text is, on the web; that it is not, yet, is something of an afront to my sensibilities. Let us fix this pressing problem.
Maybe we need display: music , too? Okay that was a mean joke and I did not mean it, everyone just calm down. Jeez.
Jen Simmons has written a stellar piece for the WebKit blog about masonry layouts and a proposal to introduce them in CSS Grid Level 3:
At its core, CSS Grid Level 3 provides a mechanism for turning off rows. It lets us create a columnar grid — a grid that’s made up of columns alone.
Neat! Masonry layouts are typically seen as Pinterest-esque interfaces and they’ve often been a bit painful to make (although it has been possible with JavaScript as Andy Barefoot showed back in 2017). Thankfully Jen shares half a dozen demos beyond the typical image waterfall example that I’ve seen many times before and so it’s clear how useful this sort of thing might be for complex typographic layouts like this example. Exciting stuff!
Okay, show me the proposal!
.container {
display: grid;
grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
grid-template-rows: masonry;
}
That last line is where the magic happens. Effectively what you’re telling CSS Grid to do here is to ignore any rows so you can create an asymmetrical grid. However! There is some drama about this proposal as some folks argue that masonry layouts should instead be toggled on the display property like this:
.container {
display: masonry;
}
Since Jen is asking for feedback in her post about this proposal, here’s my take on all this hot drama:
- Having another display option like
display: masonry; feels wrong to me and before I even got to Jen showing the proposed CSS, I imagined masonry layouts as simply being CSS Grid but with rows turned off.
- In the
display: masonry version of CSS, I would definitely forget what’s available in Masonry layouts versus Grid layouts. I guarantee I’d have to look up what grid-like options (such as gap or grid-columns or whatever) were possible and I fear, like Jen does, that they’d get out of sync somehow between browsers.
- I was sort of happy when we stopped using
columns in CSS and moved to CSS Grid but with this masonry option we’d have to go back to that? That feels like a bummer to me. I don’t want two separate syntaxes to denote columns in CSS! I am the problem!
- I had a maybe-dumb-thought whilst reading the proposal: what about masonry layouts where you can turn the columns off but keep the rows? So a horizontal masonry layout with
grid-template-columns: masonry instead?
- Nope, okay. That suggestion broke my brain and I think I’ve forgotten both how CSS Grid works and my own name now. Please send help.
Anyway, I think we should go with Jen’s suggestion of masonry being a subset of options within CSS Grid. That’s the most reasonable, maintainable, and nice-to-the-platform option available with this proposal I reckon.
