Design and Development

Effective development of any project (whether web or otherwise) requires effectively “scaling” the code-base. The experienced shops like Amazon break their code into services - modular components that are easy to understand and maintain by a small group of developers. I don’t need to hark on the benefits of modularity, but one can never overstate the importance of having a “shallow” code-base. The best software architects know this, and the big shops apply these techniques effectively.

However, from my observations, CSS always tends to get left out of good code-base architecting. That’s probably because designers who work with CSS only do it as a means to and ends - getting a pretty and usable design, while developers who work with CSS couldn’t run away from it fast enough. It’s stuck in some void where people approach it with a 10-foot pole.

Oddly enough, it’s CSS that is often in most need of solid architecting. After all, the “language” (if you can call it that) sucks, was poorly designed, doesn’t work consistently in most browsers, isn’t DRY, and makes people want to take a sip of the old table driven kool-aid once in a while.

Here’s how I approach the problem:

1. Break your CSS files down. Give your CSS files short, easy to understand names. “basic.css” is not a good name. What’s basic about it, exactly? “main.css” is a poor name. Is it the main CSS file or CSS for the page called main? I like to use “common.css” for CSS patterns (more on that later), “style.css” for styling only (more on that later) and “x.css” for pages called x.
2. Use an asset manager. This goes with number 1. Breaking your CSS down into small chunks means more round-trips if you <link> each stylesheet. Go with an assest manager to bundle all those files for you. For example, try bundle-fu for Rails.
3. Separate styling and layout. Styling is what your <em>s <strong>s <h1>s look like. Layout is probably specific to the page. Get detailed. “styling.css” can be for basic HTML elements, “styling-modules.css” can be for styling specific to reusable modules, etc. Developers call it separation of concerns. CSS designers call it sanity.
4. Don’t put IE specific hacks into their own file. (Only do this if you don’t care about validation.) This flies in the face of convention wisdom. Well, the next time you’re wonder why something looks different in IE after pouring through your CSS, only to realize 30 minutes later that something’s inconsistent in “ie6.css”, don’t forget what I told you here. IE specific CSS files are un-DRY. Instead, put the hacks as close to the non-hacked CSS as possible and document it.
5. Use common patterns. People spent countless hours on things like clearfix and the holy-grail so you don’t have to. Put these common patterns into their own file (I like common.css and common-layout.css) and don’t mess with that file.
6. Use a reset. This is an extension of #5. Resets means your CSS works tabula rasa. No more wrestling with inconsistent browser defaults. Try these reset rules. Make sure you document any exclusions for bandwidth saving reasons.
7. Use white-space effectively in CSS files. This one doesn’t work for me, but I’ve seen people swear by it. Use indentation to mimic the DOM hierarchy when you’re doing complex selectors.
8. Document CSS like you would document code. And realize that sometimes the best documentation comes from having well thought out CSS in the first place, just like how good code documents itself. If you’re working in an environment where many people are touching the same CSS files, having everyone understand the organization (see #1) is the only documentation you’ll need.

I’m sure there’re are more best-practice approaches to “scaling” CSS so that more than one person can work on it without going bananas, but these work well for me. Heck Ronin only uses a subset of these rules, and it’s already saving me my sanity. Google around and maybe you’ll find more to add to this list.