The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
There’s a difference between fault and responsibility.
Teams based on fault fall apart in emergencies. It’s because fault isn’t real. It’s a relic of the dead past. Read some Asimov.
Look, anyone who watches Star Trek (instead of reading Asimov, I guess) knows that time’s arrow only has one direction. Responsibility’s arrow matches that direction. Fault’s doesn’t.
In fact, fault’s arrow points in the wrong direction entirely. Fault points backwards, and that’s where your team will be going if you follow it.
Fault’s probably important on some level for identifying people-shaped problems on a team. But that sounds like a management problem. That’s not one of the things this book is vaguely about. If this book were about people-shaped problems in the technology industry, it would be much, much longer.
Making mistakes is, most of the time, fine. It’s even sometimes a good thing. A person who works a lot will make more mistakes. The person making the most mistakes on your team is probably also the most productive. This makes sense, I promise.
Making mistakes twice is usually a problem. You shouldn’t be making mistakes twice, especially big ones.
Teams that never make mistakes aren't trying hard enough. Teams that make mistakes twice aren’t self-correcting enough.
When it comes to CSS, there should be one person responsible for it. If you’re reading this book, there’s a good chance it’s you. CSS isn’t a black box in any project so other people are going to be screwing things up a whole lot. You’re still responsible for these screw-ups, even if you’re not at fault. You need to be the one leading the charge in helping the team not screw up in that particular way again.
This is how you should build up your CSS workflow, based on stuff you need, not ought-to-haves. Put in minifying when you near your size ceiling. Put in checks for missing CSS files after you push to production without styles. Be flexible and forgiving of yourself and anyone else who participates in the design of your product. If you’re doing things right, that should be everybody. And also nobody. You want the benefits of CSS without the drawbacks. Do CSS without doing CSS.
CASS can’t fix the accountability and responsibility issues on your team.
But it’s great in emergencies.
If you need to rebuild some lost page really fast, CASS is the best tool to get it looking right fast. Patching production live? CASS is your friend. Rebuilding in plain HTML the portion of your Angular app you accidentally deleted? Do it faster with CASS.
Need a quick “The site is borked” page for maintenance? Yep, CASS will let you do that in about a minute.
As far as doing CSS without doing CSS, well, that’s the whole point of the library. Simple but effective, crafted with love in California.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
