#276: Future-Friendly Layouts and Design System Vitals

[Robin]: I have a terrible confession to make: I still think in media queries. When I’m working on a design that requires changing the layout, I always turn to media queries to help me out. This isn’t a problem, and it works and all. These days, though, we should probably be thinking a bit differently, like this…

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(16rem, 1fr));
  grid-gap: 1rem;

As I was working on a project this week I remembered this example above from Andy Bell’s Pen which you can see in action here:

See, with that one line of CSS with grid-template-columns, you can effectively create an infinite column grid:

grid-template-columns: repeat(auto-fill, minmax(16rem, 1fr));

It’s a bit scary if you’re used to writing media queries! So, let’s break it down some more:

grid-template-columns: repeat(...)

When we use grid-template-columns we can write something like grid-template-columns: 1fr 1fr 1fr 1fr; which will set 4 columns to be the same size. To make things easier for ourselves we can write repeat(4, 1fr) and it’ll do the same thing.

But! This is a problem because on smaller screens: we might want to have two columns, then four columns, then eight columns — and so on — as the browser viewport increases; we want the number of columns to change depending on how much space there is.

We can use the minmax() function to help us out here…

grid-template-columns: repeat(4, minmax(250px, 1fr));

This sets the minimum size of each grid column to 250px with a maximum of 1fr. The problem is that we’ll always have four columns though! Like we just said, what we want is 2, 4, 6, 8, etc., depending on how much space there is in the grid.

That’s where the auto-fill keyword comes in. Sara Soueidan wrote a great piece about this a while back and gives an example like this:

grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));

This why, we’re not setting a specific number of columns, but as many that can fit in the space available. Great! In this blogger’s opinion, auto-fill is magic and it’s what unlocks CSS Grid superpowers. (Though do check out Sara’s post, because it clearly explains the differences between auto-fill and auto-fit.)

Now, this sure looks like an awful lot of new stuff to learn just to avoid writing media queries, but I’d say that this newer way of thinking about responsiveness is much more…web-y. You’re no longer thinking about mobile, tablet, and desktop devices; instead you’re thinking about how much space the content can fill up and just let the browser do the layout work for you. Content-first design! Heck yeah.

[Chris]: There is one little extra thing I think you should pretty much always do in these style of grids, and I’ll let you read about it at the end of the chapter on flexible grids in the book.

?? ??

Public service announcement: the aspect-ratio CSS property is now really well supported! I was waiting on it for a while but totally forgot that it’s now available in every major browser. Here’s how to use it:

.element {
  aspect-ratio: 2 / 1; /* ↔️ is double the ↕️ */

.element {
  aspect-ratio: 1 / 1; /* ⏹ a perfect square */

It’s the perfect CSS property because it takes something that once required a really annoying hack but is now just a single line of CSS. Boom. Easy.


A few things caught my eye on web.dev this week. First up is this post about an animation smoothness metric. It’s a real deep-dive into how to make animations on the web buttery smooth and it looks like there’s a bunch of exciting additions coming to DevTools in the future to help us make our animations better.

Next up is this piece by Brendan Kenny all about Lighthouse user flows. It’s an API that allows you to see how users are interacting and navigating around your website and what impact that has on performance, accessibility, “best practices,” and SEO. Here’s an example:

Once a web page fully loads, your Web Vitals score could be pretty dang good. But as soon as someone starts to navigate around your app, perhaps this creates all sorts of problems with performance and, up until now, those problems would be pretty hard to detect.


“Yes, design systems do improve developer efficiency and design consistency.” So says Sparkbox. They ran a test to see how much faster their eight developers were when they used a design system versus not using one at all and creating everything by hand. The devs made a form first without a design system and then they did it all over again (at a much later date) using IBM’s Carbon design system, which they’d never used before.

And the results?

Using a design system made a simple form page 47% faster to develop versus coding it from scratch. The median time for the scratch submissions was 4.2 hours compared to the 2 hour median time for Carbon submissions. The Carbon timing included the time the developers spent familiarizing themselves with the design system.

Now, this isn’t a truly scientific test and all, but I think it’s helpful in showing the bigger picture when it comes to design systems: they make things way faster and easier and more accessible.

This reminded me that there’s an interesting problem here: because we don’t have metrics when it comes to design systems that we can point to and say “ah yes, this specific thing with our forms is a problem” it makes it real hard to argue that your organization or team or what have you should care about design systems in the first place.

(If you can’t see the problem, you can’t solve the problem.)

So, I started thinking: what if we had something like Web Vitals—Google’s performance metrics—but for design systems? Imagine you could (somehow) get your design system to tell you what the productivity, consistency, and accessibility problems were to point you in the right direction?

I know these metrics are a bunch of nonsense I just made up on the spot, but something like this could be useful because I feel like today we’re sort of roaming about in the dark when it comes to design systems. We feel the problems in a design system and in a front-end codebase, but it’s difficult to get a sense of their relative importance together. Should our team be working on fixing these form components or should they tackle those accessibility problems over there with our buttons? I dunno, man. Your guess is as good as mine.

This reminds me that Figma released something like this a wild back called Design Systems Analytics

…but, as useful as that might be to some, I don’t see Figma as the design system really. It’s a piece of it, sure, but it’s a mighty small part. The code is the design system, and there’s no real good way today to get insights into that part today. Or, what I’m starting to think of as Design System Vitals.



This Pen from George Francis is amazing and also baffling: Magically Rearranging Patterns with Houdini. It only works in Chrome today, but instead of a background-image being repositioned as you change the screen size, something much more interesting is happening here:

See how the shapes don’t collide? That’s because George is using the CSS Paint API to change the shapes in the background so that they don’t touch at all. This was somewhat inspired by Chris’s random grid art:

Although it doesn’t use the CSS Paint API, it’s most certainly neat. In that demo above though, Chris uses aspect-ratio to create the little squares there and the auto-fill property I mentioned earlier:

.grid {
  --gap: 1px;
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(18px, 1fr));
  gap: var(--gap, 1px);
.cell {
  aspect-ratio: 1 / 1;
  background: red;

Oh, and on a separate note, George has been doing some fascinating work with generative art that’s worth checking out, too.


I somehow missed vscode.dev, a browser-based version of Visual Studio Code. I know I’m a little late to the party, but opening up a code editor in my browser is simply amazing. It’s like when I saw Google Maps or Figma for the first time, I sort of didn’t know how to process it.

It’s truly impressive:

This was released earlier last month and Chris Dias wrote about bringing VS Code to the browser:

Modern browsers that support the File System Access API (Edge and Chrome today) allow web pages to access the local file system (with your permission). This simple gateway to the local machine quickly opens some interesting scenarios for using VS Code for the Web as a zero-installation local development tool…


Never miss another mission-critical issue in your software again

Blast bugs and create a lightning-fast issue resolution workflow with Raygun Alerting. Set alerts based on an increase in error count, a spike in load time, or a new error occurrence, with custom filters that give you more control than ever.

The Best Realtime WordPress Backup Plugin

If you make money from your site, or spend hours perfecting content, you need WordPress backups. Protect your investment by getting your site back online in seconds with Jetpack Backup, now a standalone plugin for WordPress. Our automated backup plugin is powerful enough for pros, but easy enough for beginners. Save every change and get back online quickly with one‑click restores.

[Chris]: There was a fella who went by the moniker _why. Klint Finley has a nice remembrance piece on him for GitHub’s README project (which is apparently a thing? Sorta like Stripe’s Increment, I guess, which is sadly shutting down). Anyway, remembrance? Is he dead? No, he just peaced out of the internet in a very extreme way (“infocide”) on August 19, 2009.

He deleted his website, his social media profiles, and his GitHub account along with all the projects he had created. 

Gonezo. No warning, no new caretakers for projects. Just a self-deleting of digital self. And dude was massively influential. A book that made Ruby famous, a popular blog, Twitter, loads of conference appearances… but he’s perhaps most famous because of how weird and eccentric he was, while at the same time being good in that he wanted people to understand programming and help next-gen programmers.

Klint theorizes that perhaps the meaning of this extreme infocide approach is exactly the opposite of what it seems. Rather than be successful in wiping one’s self from history, the act of trying ensures that such huff is made out of it that people step in, save everything, and thus ensures a longer legacy than perhaps you would have gotten alone.

I hate it. Live your life. Do a good job. Maybe if you do good enough they’ll put a bench in the park with your name on it. Don’t commit (even a virtual) suicide just because you want a statue instead.