I’ve read a lot of articles and a few books that detail various methods for web designers to split up their CSS files. Authors have recommended splitting your CSS files to include individual CSS files for fonts, another for colors, another for structure, and the list goes on and on. The WordPress default theme comes with a CSS file that has tons of duplicate declarations.
Reduce page load time
One issue that quickly arises if you start forking your CSS like this is the number of HTTP requests that your pages are making. Since your average browser can only make 2 HTTP requests at any given moment, the splitting of CSS files into separate files therefore can slow down load time on your pages. The same rule applies for your JavaScript files, as well as CSS background images. If you can combine all your CSS background images into one larger image map, and then position them correctly via the background property, you again reduce the number of HTTP requests per page. This and many other rules are detailed at the Yahoo Developer Network in their page on Best Practices for Speeding Up Your Web Site. This page also happens to be the basis for the YSlow Firefox plugin, so if you don’t feel like reading all the rules, just download the plugin and run an analysis on your homepage. It will tell you if you have too many HTTP requests right off the bat.
Don’t keep ‘em separated
The other problem that just gets under my skin is having duplicate CSS declarations. I hate going through a CSS file to find that I have 3 different declarations for my h3 tags; one that sets the font-size, another that defines the margins and a third that sets it as an inline element. Again, I know this can’t be avioded and is even beneficial in some cases, but the majority of the time I find myself combining as many declarations as possible simply for clarity’s sake. The entire theory behind splitting your CSS files based on fonts, colors, etc. is based upon this duplication of CSS declarations, and I for one think its rubbish. The smaller our files are the better, right?
Necessary decisions
I personally like to split my CSS files out of necessity, not practicallity. Rather than loading up one main site CSS file with a bunch of Internet Explorer X-specific hacks, I would much prefer to stick them in an IE6 or IE7-only CSS file. This serves a few purposes. If you place your IE6 or IE7 style sheet references in conditional comments, like this we do on this page (check your source!), they don’t get read by smart browsers. So you’re not feeding excessive and unnecessary code to new, standards-compliant browsers. Second, it makes it really, really easy to drop support for an older browser once its no longer needed. For example, what happens when IE8 is released (we’re waiting) and we can safely remove support for IE6? First, we’re throwing a party. And not just because we don’t have to test in IE6 any more, but more because to drop support all we had to do was change one line of code rather than digging through all our CSS to find the old hacks. We may even start the party first, and then drop support for IE6 for all our sites in a total time span of 5 minutes, after having a few cocktails, just to prove once and for all how easy it is, and why this is the only reason you should ever split your CSS.
Molly Holzschlag wrote an article a while back that details the different ways you can setup your CSS files to cater to different browsers via @import and the like. Check it out at the Peachpit site.
If you’re going to split your CSS into separate files, make sure its for the right reason.
