A drafting table

CSS Architecture

Over the last few weeks I’ve been digging into CSS architecture, wanting to learn how large organizations are working to keep their code organized.

Along the way I’ve picked up a ton of useful tips that will change the way I write CSS going forward, which I’ll share here.

I started by reading SMACSS by Jonathan Snook, which I actually re-read a couple times and ended up heavily marking up with notes. In a way, this marked-up SMACSS book has become my notebook on css architecture. It sits near my computer as a reference guide and gets notes added to it as I find more info on the internet.

The two other resources for CSS architecture that I started reading was Harry Roberts’ articles over at CSS Wizardry, and Nicole Sullivans’ work with OOCSS. Both have similar messages and are creating new ways to think about how we write our code.

What really tied it all together though was watching this video from Andy Hume at SXSW. If you haven’t seen this yet, do yourself a favor and take some time to watch. There’s tons of great information in it.

So, after studying and learning as much as I can on CSS architecture, I thought it would be good to write down some of the key ideas that I’ve picked up on. This is not an exhaustive list, but here are some thoughts to get you started:

1. Find patterns

The overarching rule to CSS architecture is to learn to identify patterns. Patterns simplify your code. Learning to identify patterns and write reusable CSS will make you code leaner, DRY and much easier to maintain. Writing smart CSS will invariably mean that you’ll be writing less CSS.

2. Separate your concerns

The #1 benefit for me, by far, has to be the organizational aspect of CSS architecture. It keeps you organized by separating your code, which has been common place in other languages for a long time. This is a core idea of OOCSS.

3. Be intentional with your CSS

what I mean by this is no more of this:

.nav ul li a{ }

When a much leaner selector like this would work better:

.subnav{ }

SMACSS address this as ‘minimizing depth‘, while Harry Roberts talks about this as the difference between using a sniper rifle vs. using a grenade. This has performance issues related to it since CSS gets evaluated right to left by the browser. It makes no sense make the browser work harder to find your intent.

4. Don’t make your selectors do too much

This is bad:

.thing{ position: absolute; top: 15em; right: 10em; background-color: green; text-transform: uppercase; font-size: 2rem; line-height: 1.2rem; }

This is bad because it’s not reusable. It’s also defining the look and feel as well as the layout and position all in one rule. This can be modularized like below:

.thing-layout{ position: absolute; top: 15em; right: 10em }
.thing-module{ background-color: green; }
.thing-title{ text-transform: uppercase; font-size: 2rem; line-height: 1.2rem; }

This is still not perfect, but it’s much improved, and best of all it’s reusable. The class .thing-title can now be used wherever we want; it’s portable. It also separates our skin from the structure. This lends itself well to the idea of finding a solution once and using it over and over again.

5. No ID’s.

They’re just bad news all around. I know there are arguments for using them, but unless you need it for a JS hook, or a anchor, there’s really no need to.

6. Comment, comment, comment

There’s really no reason not to write as many comments as you can. I’ve always tried to keep my code well commented for my own reference, but when it comes to large teams it’s absolutely vital. You need to explain your decisions to others clearly, and there is no better way than writing good comments.

As I said, these ideas don’t cover all of CSS architecture, and there are certainly exceptions to every rule, but I think they  provide a good starting point.

Here are some additional resources that I’ve used to learn more about CSS architecture as well. I highly recommend each one:

John Rohan on CSS performance at Github

Harry Roberts on big CSS 

Nicolas Gallagher on front-end architecture

Phillip Walton on CSS Architecture

There are no comments

Your email address will not be published. Required fields are marked *

five + fourteen =