Combating Classitis with Cascades and Sequential Selectors

Published March 10, 2008 by Rob Glazebrook.

stethoscope

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.

32 Responses

  1. Justin (reply)

    What I always hate seeing is uncombined border styles.

    border-top: 1px solid #000000;
    border-right: 1px solid #000000;
    border-bottom: 1px solid #000000;
    border-left: 1px solid #000000;

    Or border styles broken out to specify different colors on different sides, like so:

    border-top: 1px solid #FFFFFF;
    border-right: 1px solid #000000;
    border-bottom: 1px solid #FFFFFF;
    border-left: 1px solid #000000;

    …when the same thing could be more briefly written as:

    border: 1px solid #fff;
    border-color: #fff #000 #fff #000;

  2. chris Coyier (reply)

    It’s important to think about semantic meaning here too. Consider using something like “callout” for a class name instead of “red”. That has more semantic meaning to the markup so that down the line if you decide to change the color for those elements, you won’t be stuck with a meaningless “red” describing them.

  3. Pingback: Links of Interest - CSS-Tricks

  4. Benjamin Doherty (reply)

    IE6 doesn’t support multiple classes in a single declaration, so while putting two classes in the element works, combining two classes in a single declaration —

    p.big.red { text-decoration: underline; }

    — isn’t going to work.

  5. Dave (reply)

    Chris’s comment is spot-on how I feel. I cringe when I see classes like “big” and IDs like “box1″ “box2″ “box3″ instead of IDs “Headlines” “Calendar” “Questions” and a generic “box” class.

  6. Rob Glazebrook (Author) (reply)

    Dave, Chris, I couldn’t agree more. Which is why the paragraph right after that example you’re talking about explains why classes such as “red” and “big” shouldn’t ever be used. :)

  7. Matt Rossi (reply)

    Nice post. I also hate it when, people are “aware” of the cascading, but try to “reset” previously defined styles again because they were just overwritten…

  8. Niels Matthijs (reply)

    Nice post although I don’t really like to use sequential selectors. This can become messy very quickly, and should only be used when the values are meant to be the same, and should stay that way even when (minor) changes are made to the design.

  9. Pingback: Carmine Web #2 » Blog Archive » CSS: tips, tutorial e risorse

  10. Timwi (reply)

    If you’re going to lecture people, maybe you should first make sure that what you’re saying is right and that you’re not contradicting yourself.

    You are trying to advise against different classes that have an identical effect. At the same time, you preach that classes should have a semantic meaning rather than a visual one. You’re contradicting yourself here. Classes with different semantic meanings can pretty damn well have identical visual appearance in any particular layout. Consolidating those into the same class just because they happen to look the same would lose semantic information.

    Your treatise about the “cascading ability of CSS” is misleading. You claim: “Once the appropriate font family had been applied to the body tag [...], all of the additional “Arial” family declarations [...] became redundant.” This is grossly incorrect. Any element (a table, say) can override the font family, and then everything inside that element would have the new font family. If I want to use the original font on an element somewhere inside the table, I have to apply the body’s font to that element, which according to your logic would be “redundant”.

    No wonder the web is full of bad CSS if people with authoritative-sounding writing skills (like you) spread so much misinformation.

  11. Rob Glazebrook (Author) (reply)

    Timwi, thanks for your very impassioned response. I’ll respond as briefly as possible.

    First, you’re correct in that elements with identical appearance can have different semantic meaning. But in that case, I’d probably suggest if possible and logical that the developer use sequential selectors, i.e. “p, .error-message { whatever; }”. That way, if you decide to make a change further down the road but still want them to be identical, you only have to make the change in one location.

    And regarding the cascading ability of CSS, I’m still not convinced I’m incorrect. If you set a font-family in the body tag, everything inside of that tag will inherit that font-family, unless you specifically state otherwise. The one exception to this rule is if you are working in quirks mode (i.e., without a declared DOCTYPE) — then, for example, tables can override font selections, and you’d have to be more specific. But I’d never recommend anyone work in quirks mode if they could avoid it.

    Maybe I should have specified previously… when writing these tutorials, I’m assuming the following: you’re writing sematic and valid XHTML, you’re building from the ground up (e.g., no nasty font tags to worry about), and you’re not operating in quirks mode.

  12. Pingback: Autodesign » Links of Interest

  13. Pingback: Links of Interest :: FULL clout

  14. Pingback: Links of Interest :: FULL clout

  15. Pingback: Best Of March 2008 | Best of the Month | Smashing Magazine

  16. Pingback: Best Of March 2008 | Best of the Month | Smashing Magazine

  17. Pingback: Best Of March 2008 | Blog

  18. tieTYT (reply)

    Wow, what a great article. You, sir, know the proper way to teach a subject: Start with an example of the wrong way, explain the problems then show us an example of the right way.

  19. Pingback: Best Of March 2008 - juliomarroquin.com

  20. Pingback: Best Of March 2008 - juliomarroquin.com

  21. Pingback: ifoh designs » Blog Archive » Why your site sucks - Web Design That Is Neat.

  22. Pingback: Build an American Flag out of XHTML and CSS - CSSnewbie

  23. Pingback: New to CSS? New to CSSnewbie? Start Here! - CSSnewbie

  24. Pingback: WEB 3.0 » Blog Archive » ¿Así que querías saber (casi todo) de CSS?

  25. Pingback: WEB 3.0 » Blog Archive » ¿Así que querías saber (casi todo) de CSS?

  26. Pingback: Essential Tips for Redesigning your Website | Chris Taylor Design

  27. Pingback: Essential Tips for Redesigning your Website « SixCrayons

  28. Pingback: Welcome to joecochran.com! | joeCochran

  29. AntoxaGray (reply)

    Classitis are not bad actually. This is new trend of 2012 (google SMACSS) and I agree with smacss guy.

    Because oversimplifying css and html makes project much less scaleable and you will have to add many redundant rules to css and it will be confusing. It’s from personal expierence not just theory.

  30. Pingback: Combating Classitis with Cascades and Sequential Selectors – CSSnewbie | Robert Palmer

  31. Dr Dre Beats Solo (reply)

    I don’t even know how I ended up here, but I thought this post was good.
    I don’t know who you are but certainly you are going to a famous blogger if you aren’t already ;)
    Cheers!

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>