Rules: CSS Formatting
October 25th, 2007 |CSS formatting
CSS files bother me since I can think of using CSS. The bigger a CSS ruleset becomes the harder it becomes to keep things separted. If it comes to debugging it can be a real pain to find the one rule inside the nested styles. One major part of that mess has always been my own fault. In the first place I just wrote down the rules, each element got it’s style, period.
Later on I found out (I think while looking at wordpress-themes, that was) that it’s a good idea to divide a CSS file into sections for basic structure, typography and so on. This was the first thing I stuck to. Then I invited my own coding structure, which I couldn’t find anywhere else until now, for whatever reason that is. It looks like this:
-
body {
-
background: url("../images/bg.gif") #333;
-
color: #fff/*colInverted*/;
-
font-family: georgia, serif;
-
font-size: 100%;
-
}
-
-
#mycontent {
-
background: #fff /*colInverted*/;
-
border-color: #333 /*colText*/;
-
border-top-color: #bbb /*colSoftX*/;
-
color: #333 /*colText*/;
-
}
So the basic idea is to have all rules, codeblocks and values begin at their own consistent column. Additionally I adopted an idea from 70 Expert Ideas For Better CSS Coding and am sorting the properties alphabetically. Finally I am using constants in a way like this:
-
/**
-
* Constants being used in this file:
-
* #fff/*colInverted*/ /*
-
* #333/*colText*/ /*
-
* #666/*colSoft*/ /*
-
* #bbb/*colSoftX*/ /*
-
* #333/*colHighLight*/ /*
-
*/
Using those I can easily change every notation of a color in the whole css file using a simple search & replace. (Note that the constant-name-comment is written before the semicolon, so the search & replace also works with short notations where the constant may not be the last value in the ruleset, plus there’s a space between the value and the /*-opening comment, this is for better browser compatiblity) Finally I split up the CSS into various files:
- reset.css
Reset file to cancel browser default values. - main-layout.css
Define the dimensions and positions of the main layout elements - baseline.css
Rules to keep everything on the baseline grid, with lots of ugly 0.xxxxxx – em-values - boxes.css
Rules for other semantic areas within the layout (e.g. side column) are defined here. - color-typo.css
Typefaces and colors, nothing else. - links.css
Appearance of all links - toolbox.css
All kinds of special effects and layout-hacks.
Footnote: One big disadvantage about css frameworks is that they can produce a hell lot of http-requests. I saw frameworks split up in 20+ files, what for my personal bloggy is irrelevant, but any bigger page has a good chance to suffer from that. Keep in mind that every single file has to be fetched from the server (I know caching helps here, but hey – 20times as much requests? come on …). Whilest I see the advantage of keeping single parts split up that’s not an excuse. A simple server-side script that, let’s say once a day, checks if any css-framework files have been updated and, depending on that, builds one complete file from all the single parts will solve this problem without having any disadvantages. Also this script could strip unnecessary comments and whitespace as well as it could gather the data from one central location, making administration of the framework even more easy.