The Cascade is a blog about the past, present, and future of CSS.

Howdy—Robin Rendle here.

We’re living through a golden age: CSS was once a language that was easy to make fun of but has now transformed into a serious and expressive toolkit for building visual interfaces. Although making fun of CSS was always lame, today, in 2024, it shows a deep lack of curiosity. The train has left the station. CSS rules. Get with the program.

But this didn’t happen randomly. Thousands of dedicated, smart folks have worked tirelessly over decades to get us to this point where CSS is—in this humble blogger’s opinion—the best design tool ever made. Every day some new super power is unlocked for us in browsers and with each new power the web becomes a better place, thanks to them.

So this blog exists to keep me in the loop and somewhat up to date with everything that’s possible with CSS but also it’s a reminder to celebrate the people doing the hard work building these tools for us.

You can subscribe to The Cascade via RSS, shoot me an email if you absolutely must, or follow the feed. This project is directly supported by readers and the membership program.

Right now the newsletter is taking a bit of a break whilst I figure out a healthy publishing cadence, but you can subscribe below:

Invisible success

Eric Bailey has some great thoughts about why it’s tough to show success on a design systems team:

In a business context, design system work means numbers go down. Less bug reports, faster design iteration, shorter development cycles, fewer visual inconsistencies, smaller staffing requirements that enable folks to work on more interesting challenges, etc. All good things.

Unfortunately, contemporary business practices only reward numbers going up. There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.

This is an interesting discussion because it’s hard to quantify what’s good work when it comes to design systems. For example, when I was on a team like that I would struggle to make the case for refactoring tons of janky and confusing CSS.

Ultimately I felt like I was good at the systems part—I could tell when there were too many similar components or when we should refactor something—but I was really, really bad at the storytelling part of design systems. And that kind of work is really more story than systems: explaining to folks up the chain why this seemingly insignificant series of tasks is an investment in the future. Or why this one tiny detail is worthy of our care today so we don’t have to worry about it later.