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 project has too much HTML. There are too many tags. They’re nested too much. It’s tough to read. It’s hard to work on.
You suck at HTML.
You’re probably doing a whole lot to hide this. But it doesn’t matter what framework you use or how you architect your project. HTML bloat works anywhere, on anything.
If you have to dive through eight nested levels of badly named divs, your slick data flow architecture won’t do much to save you time when you have to make tiny changes.
Bad HTML takes longer to render too, so it’s not just gumming up your time but the computer’s time too. Bad HTML takes longer to change with scripts or to change the look with CSS, both for the person writing the CSS/JS and for the computer executing those instructions. It exacerbates all of the problems in the modern memory-hogging browser setting.
When you’re writing HTML, try not to nest more than three levels. IDs are like bookmarks for your document-- fast to access. Classes take longer because your code has to look through the whole bloated document to find them. They’ll seem fast when you first use them. Then they’ll be slow months later when the page is huge.
Remember the flat design trend? Think of avoiding nesting as flat information design.
Your whole document will be bigger and take longer to look through if your HTML is bloated. This won’t be obvious at first. It’s an easy corner to paint yourself into.
Eventually, if you let the problem get bad enough, everything you do will be complicated by markup bloat.
To stop the bloat, you could simply stop adding stuff. You’d probably get fired though, right? Your job is adding stuff, according to at least one person who can fire you.
Also, if enough people like your product, they’ll be asking for new stuff all the time. It’s really a Mexican standoff between you, the askers, and the person who can fire you. In the middle is markup bloat.
You can also simplify as you go. If you’re always adding stuff, make sure you’re always simplifying too.
Deleting is the best form of simplifying. If you’ve architected things well with CSS disposability in mind, then both markup and CSS will be relatively easy to throw away.
Perhaps the best way to avoid markup bloat is to develop a complete and total aversion to nesting. This will help you in both architecture and optimization. Following some “Don’t nest more than X levels” rule isn’t good enough. It needs to be a visceral avoidance, like the kind you feel for writing good git commit messages.
Sometimes you do just need to nest a whole lot. Just not on your marketing landing pages. Or the navbar for your site. Or the footer. Or anything else that should just stay simple.
CASS’s composable classes are designed to keep your HTML simpler in structure.
The classes do stack up, though, so it adds a bit of complexity back too. An element may very well have something like padding light white border thick rounded shadow which gives the element padding, a light white background, a thick border, rounded corners, and a box shadow. It’s a lot to say, but it’s saying a lot.
There’s always a trade-off though. It’s one of the inescapable rules of software development. CASS makes this tradeoff because the thing gained is time. Time’s the big one. You could instead give the previous example the .light-card class, but then whoever read it next would have to look up what that meant.
CASS itself does encourage nesting sometimes, particularly in layouts that have columns inside of columns. Those always have to be a few levels deep. Most of the time, if you have too much layout complexity you can abstract it away with a framework. Then you can go back to nesting 1-2 levels at most.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
