A useful resource for CSS grid. It’s basically the spec annoted with interactive examples.
Some great practical examples of progressive enhancement on one website:
- using grid layout in CSS,
- using the
pictureelement to provide
webpimages in HTML.
All of those enhancements work great in modern browsers, but the underlying functionality is still available to a browser like Opera Mini on a feature phone.
A cute walkthrough for flexbox and grid.
Like a little mini CSS Zen Garden, here’s one compenent styled five very different ways.
Crucially, the order of the markup doesn’t consider the appearance—it’s concerned purely with what makes sense semantically. And now with CSS grid, elements can be rearranged regardless of source order.
CSS is powerful and capable of doing amazingly beautiful things. Let’s embrace that and keep the HTML semantical instead of adapting it to the need of the next design change.
A series of really nice CSS grid demos based on two-page magazine spreads.
min() gets better support (it’s currently in Safari), we’ll be able to create container queryish declarations like this:
grid-template-columns: repeat(auto-fill, minmax(min(10rem, 100%), 1fr));
CSS grid and custom properties really are a match made in heaven.
This is a really good explanation of the difference between context-aware layouts—that we’ve had up until now—and content-aware layouts, which are now possible with CSS grid:
autokeywords, we can size grid tracks based on their content. I think this is very cool. If we manage to embrace as much of the web’s flexibility as we can, we can get the most out of these tools, and let CSS help us with designing for the unknown.
This is a really nice glanceable reference for CSS grid.
CSS Grid is easy to use but difficult to learn. It’s a more intuitive paradigm than any other CSS layout technique, but it’s completely different from its predecessors.
Some great advice here on how to approach CSS grid:
- Use names, not numbers
- Use fr as your flexible unit
- Don’t use a grid system
Hidde takes one iconic design and shows how it could be recreated with CSS grid using either 4 columns, 9 columns, or 17 columns.
I think Cathy might’ve buried the lede:
The knock on effect of this was removing media queries. As I moved towards some of the more modern features of CSS the need to target specific screen sizes with unique code was removed.
But on the topic of Sass, layout is now taken care of with CSS grid, variables are taken care of with CSS custom properties, and mixins for typography are taken care of with
Personally, I’ve always found the most useful feature of Sass to simply be that you can have lots of separate Sass files that get combined into one CSS file—very handy for component libraries.
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
Remember when I said that if we want to see CSS exclusions implemented in browsers, we need to make some noise?
Well, Rachel is taking names, so if you’ve got a use-case, let her know.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
But despair not—Rachel points to a potential solution. I saw potential solution, because if we want to see this implemented in browsers, we need to make some noise.
‘Sfunny, this exact use-case (styling a profile component) came up on a project recently and I figured that CSS grid would be the right tool for the job.
A terrific piece by Hidde, about CSS grid, but also about a much bigger question:
I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.
If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.