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.
Your codebase should make sense even if the folders don’t have names.
For CSS you should think of your codebase as a series of resting points for your CSS before it gets thrown in the garbage.
The best way to organize your CSS is the Core/Components/Pages pattern.
Your core CSS should be a versatile base you can use anywhere. Roughly speaking, it’s a California Stylesheet, plus anything else you’re going to use absolutely everywhere on all projects.
Components are, well, components. Or your styles for them. They can show up again and again in different spots.
Pages are where you put your page-specific styles or CSS you wrote for one-off components that will only show up on a single page.
CSS might migrate. Page-level stuff you like could become its own component. A component you really relied on could become part of core. This is one of the very few processes by which CSS becomes less trash.
Where do you put these things in your CSS file? Well, we’re talking about codebases here. You put them in folders in your codebase.
A CSS file is the most disposable form of CSS, which we’ve established over and over is already itself destined for the garbage heap. If you organize your codebase appropriately, then you can create CSS files for any occasion. CASS lets you do this by swapping in a new California Stylesheet with different settings, or by overwriting those settings in your own theme.
Your CSS file should cover the page that’s showing it. The style codebase is what needs to cover everything. At first they’re the same thing but if your project is big enough, you’ll need lots of different CSS files. CSS turning into too much CSS is a recurring problem in web development. Don’t worry about it at first but be ready for it later.
What’s great about the core/components/pages pattern is that it makes it easier to delete CSS. Deleting CSS should make you happy. Deleting CSS is almost as good as not having written it in the first place.
Crappy code that can easily be deleted is better than crappy code that is used by some other part of your app and can’t be deleted. Keep that in mind when you architect.
Your effort should match how close to the center of the project the code is. Libraries should be pristine and spotless because they’re intended to be used by others. One-offs and stuff that won’t be maintained can be downright bad. Yes, making something bad is objectively correct sometimes, if bad also happens to be good enough and saves time or resources.
Architecture is an evolving process early on in any project. CASS lets you worry less about CSS during this time, freeing you to work on the architecture of how your project works, not the architecture of how it looks.
CASS lets you toss away traditional workflows and processes that just eat up time early in a project.
Early’s when time is the most important.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
