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.
The best way to suck at web development is by having high standards.
Here's the big secret about standards: They're a project-level concept, not a developer-level concept.
Throw your personal standards in the trash, where they belong. Save it for your personal projects, where you're the only one who has to suffer through your manicured, everything’s-perfect codebase. Or your uncommented spaghetti mess.
Developers who bring their own standards to a project, too high or too low, create mismatches between their imposed standards and the ideal standards for the project.
Mismatches like this are always bad for the project.
These high-personal-standards developers are like pilots who insist on flying everywhere, even down the street to the grocery store. And they want everyone else to do it, too. Insisting on tests, or type systems, or comments, or tabs, or any of a million other standards makes you a bad developer.
Recognizing when a project needs such a thing, and insisting it be added to the project as a standard? That's great. Imposing it just because that's your personal line in the sand for development? Not so great.
Perfect is the enemy of good. Good is the enemy of good enough. Good enough is the real perfect.
Bad developers insist on perfect. Good developers make it good. Great developers leave it at good enough.
The best code is code that just barely works but still never needs to be looked at again. Any code that’s better took too much development time to do the same thing. Any code that’s worse will break and need to be looked at.
If you’re a project manager with no technical background, this is your weak spot. You’ll eagerly agree to fly to the grocery store down the street, having no idea of the impracticality of the situation.
I digress. What was I talking about? The Yeats family has a tendency to ramble. Sorry about that.
Ah, right. Standards.
Where does this leave CSS, standards-wise? Before forming project standards for CSS, it's important to internalize one thing: CSS is disposable. Making things good enough is a good strategy for any code you write, but it’s especially great for CSS.
In other words, having personal tech stack and best practice standards is bad, but having personal standards for CSS is particularly bad.
CSS is like a complexity attic for your project, where you can hide your pseudo-element driven hacks, your too-many-classes-but-whatever cascading shame sheets, and the camelCase stuff that you’ll deprecate soon, really.
CSS is a safe spot to dump complexity, particularly visual design complexity. If you need to choose between making the markup more complicated or making your CSS more complicated to make a design work, you should always pick the CSS. The reason for this is simple: The CSS is "downstream" of the markup and the scripting, while the markup is “upstream” of almost everything that renders on the page.
Avoid markup bloat as much as you can. Make the CSS complicated instead, if you have a choice.
CSS bloats too, but so long as it's treated as disposable and downstream of the markup, it can just be thrown out or namespaced away. Conventions and markup, and conventions inside of markup, are what you need to hold onto, not the CSS itself.
CASS is just a fancy CSS file with a collection of really simple, straightforward standards. Just use those. Don’t think up your own. That takes too much time. Don’t set up some workflow that manages your project standards for you, either. They should be simple, understandable and accessible directly by your user (other developers, or the actual user).
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
