Do as little as possible.
That’s the golden rule of writing less CSS.
Do as little as possible for as long as possible. Whatever your project is, you always want to capitalize on its early greenfield state.
Stop hassling your CSS. Out of any language on the internet, CSS is the most chopped up and roughed up.
It’s fine to just leave your CSS as-is, without subjecting it to anything like optimizing or minifying. There’s probably an image on your homepage that dwarfs your CSS file in size.
It’s just friction. For everyone involved in the process. For the user. For your future self. For the digital archaeologist digging up your site in 3,000 years.
Part of doing as little as possible is having a tolerance for things like inline styles. Sometimes a quick adjustment in the markup is fine. Yes, it’s not a best practice. But instances of it are really easy to find in a codebase. It’s an okay practice. Sometimes it’s good enough.
Most people hate inline styles because they’ve been stung by an inline style that they didn’t know to look for. But if you’re okay with them then you know to look for them. Treat them like a red flag thrown up by non-CSS-writers on your project. If they’re used right they do end up saving everyone time.
Being fussy about inline styles counts as treating CSS as sacred. It’s not, which is why it’s entirely appropriate to just toss something into “style=”.
CASS is designed to work without any workflow past getting CASS. You can’t suck at workflows if you don’t use one. Just like you can’t suck at CSS if you don’t write it. Solved problems are great but avoided problems are even better.
CASS is about 20kb. It’s not meant to be minified, gzipped or obfuscated anyway. It’s the whole library and it’s there every time. It’s not just an asset on your site, but an asset to your team.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.