There is a disease out there in the CSS world. It can afflict anything from the meanest weblog (or the nicest ones too, I suppose) to the greatest of corporate websites. It’s called Classitis, and I’ve encountered it far too often in my professional work. Perhaps you’ve seen it too. It looks a little something like this:
body {
font-family: Arial; }
h1 {
font-family: "Times New Roman"; }
h2 {
font-family: "Times New Roman"; }
p {
font-family: Arial; }
p.ArialRed {
font-family: Arial;
color: red; }
p.ArialRedBig {
font-family: Arial;
color: red;
font-size: 150%; }
ul {
font-family: Arial; }
ul.ArialRed {
font-family: Arial;
color: red; }
strong.redArial {
font-family: Arial;
color: red; }
This particular snippet of (completely fictional) horribly afflicted CSS suffers from multiple problems which could all probably be considered symptomatic of Classitis, even when they don’t directly involve classes. I’ll go through the five of the most glaring problems and how to remedy them below.
The Cascading ability of CSS is ignored. Notice how many times the “font-family: Arial;” rule is applied? This is a waste of space, and ignores the fantastic cascading ability of CSS (which I’ve covered elsewhere). Once the appropriate font family had been applied to the body tag (the first rule in our example), all of the additional “Arial” family declarations, because they were identical and were inherited from this first declaration, became redundant.
Simple and identical rules are repeated. Take a look at the rules for the <h1> and <h2> tags in the example above. They use a different font-family than the body tag, so it’s appropriate that they have a rule making that change. But why repeat the rule twice? With CSS, you’re allowed to list sequential selectors, separated by a comma. Instead of the rule above, we could’ve written this:
h1, h2 {
font-family: "Times New Roman"; }
Different classes have an identical effect. Consider the rules “ArialRed” and “RedArial” above. They do exactly the same thing, but the designer was in such a hurry, they accidentally created two rules that mirror one another. Always stop and consider when you’re writing your CSS if there’s any way to consolidate your rules. If you have to write the same rules multiple times, the answer is probably “yes.”
Classes are applied to multiple elements. There are two instances of the “ArialRed” class in the example above. One is being applied to a paragraph tag, while the other is being applied to an unordered list. There’s no need for this redundancy. By eliminating the “p” and “ul” portions of the two selectors, those classes can be consolidated into a single instance.
Class names are super long. This is the classic symptom of Classitis from whence the name derives, much like how chicken pox is named after the chicken-shaped virus that causes it (no? Well, you figure it out then). Designers sometimes get in a hurry and start building classes for every possible design difference they encounter. This can most easily be combated by remembering two things:
First, as I’ve mentioned before, elements can have multiple classes. Instead of having a class of “RedBig,” why not break it into two classes? Then you can style elements that need both classes like this:
<p class="red big">
This text is now red and big.
</p>
Second, classes should describe what an element does, not what it looks like. A class of “red” is great when you’re first building a site, but what happens three months down the road when you decide that you want your emphasized text to be blue? A class of “.highlight” or something similar to indicate the text should stand out in some way would have been more appropriate. Of course, even seasoned developers tend to break this rule every once in a while.
So, after we apply all of the advice offered above, what are we left with? Something that looks a little like this:
body {
font-family: Arial; }
h1, h2 {
font-family: "Times New Roman"; }
.highlight {
color: red; }
.shout {
font-size: 150%; }
Ahh… nice, healthy CSS, without all of the bloating Classitis inevitably causes.
Of course, these are just a few of the pitfalls of redundancy and excess that designers can fall into when developing their CSS. If you can think of others, share them in the comments.