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:

Design systems and strictness

A while back I rambled out loud about how some design systems are way too strict:

Being on the other side of design systems now as a product designer is super interesting. I kinda hate the rules and regulations and nitpicking! And if I can’t lean into the system then I will fight against it with every fiber of my being.

So, okay, what parts of a design system should be strict and which parts should allow for more flexibility then? For example, design tokens should probably be super strict. You should rarely add a new font size or color variable or space things out with 7px when your systems sets an 8px scale. Adding a new font to a design system should also be a very slow and deliberate process that shouldn’t be rushed. So that’s a no-go, too.

However, components should be pretty locked down. You should be allowed to add components back to the system but a design systems team should be able to step in and demand that you use the standardized Button component over NewFancyButton. Otherwise all hell breaks loose and you have 5 different versions of everything.

However, however: adding variants of a component should be pretty lenient. If I need to add a green button to the design system then I don’t think that’s where a ton of oversight should be required to stop that because a variant doesn’t do as much damage as a whole new component might.

My rambling point here with all this is that there’s a spectrum of strictness when it comes to design systems and I think a lot of the work I did in the past ignored that. I saw our component library as being this pure and perfect thing that shouldn’t be messed with. But such intense strictness actually ended up hurting our team in the long run: folks didn’t want to contribute or help make things more consistent across the product. I still struggle, generally, with wanting to be right all the time. I want to correct all the wrong-ness in the world! And when it comes to design systems there’s so much sillyness and incorrectness and misbehavior that I want to sweep it all away with a wave of my hand.

But being useful is almost always better than being right. Both in life generally and also when it comes to our work in building sustainable and kind design systems.