By Kevin Yank

CSS Frameworks and Semantic Class Names

By Kevin Yank

A bulldozer pushing the letters C S S

One of the most common complaints about CSS frameworks like Blueprint, YUI Grids, and is that they require designers to dirty their fingers by adding presentational class names to their HTML documents, like so:

<div class="span-9 last">
<div class="grid_6 alpha">

Class names like "span-9" really bother designers who care about the quality of their HTML code, because they describe the appearance of an element; this should really be left to the CSS properties defined in your site’s style sheets. The problem with presentational class names is explained especially well by the W3C QA tip, Use class with semantics in mind:


Good names don’t change. Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Maybe you’re the pragmatic type who takes no issue with this sort of thing, or decides that it’s a necessary evil given the limitations of the CSS language. Nevertheless, there are plenty of front-end ninjas out there who refuse to use CSS frameworks for this very reason.

It turns out, however, that the latest crop of CSS frameworks provide clever solutions to the problem of presentational class names.

Blueprint CSS, the granddaddy of CSS layout frameworks, now includes a clever Ruby script called compress.rb in its download package. In Blueprint’s compress.rb: A Walkthrough, Blueprint author Joshua Clayton explains how to use the script to generate a custom version of the Blueprint style sheets using your own semantic class names.

The process boils down to writing a simple configuration file that tells the script how to map Blueprint’s presentational class names to your own semantically meaningful class names. The file will look like this:

  path: /Users/kyank/Documents/myproject
    ".header, .footer": ".span-24, div.span-24"
    ".content": ".span-18, div.span-18"
    ".sidebar": ".span-6, div.span-6,
                 .last, div.last"

The semantic_classes section provides the mapping. In this example, the header and footer classes will be 24 grid units wide and the content class will be 18 grid units wide. The sidebar class will be 6 grid units wide and the last block in its row.

With this configuration file written, you simply run the compress.rb script, and the customized version of the Blueprint style sheet files (screen.css, print.css, and ie.css) will be generated in the specified path. The style sheet will contain rules like this one, that apply the grid dimensions to your custom class names:

/* semantic class names */
.content {float:left;margin-right:10px;

… and just like that, you gain all the layout facilities of Blueprint CSS with none of the HTML cruft!

If manually compiling your style sheets with a Ruby script sounds like a bit of a pain (which it can be — especially if you develop on a Windows computer without Ruby installed), a server-side CSS framework might be a better option for you.

CSS frameworks are popping up for all the major server-side programming languages. Two prominent examples include Compass (for Ruby), and Scaffold (for PHP). These frameworks let you write your style sheets with extra language features, and automatically compile them to standard CSS code when sending them to the browser.

Using Scaffold, for example, you could write your style sheet like this:

@grid {
.header, .footer {
.content {
.sidebar {

The @grid at-rule sets up the options for Scaffold’s layout plugin, and then lines like +columns(24); (called mixins) are compiled into standard CSS properties when the browser requests the style sheet.

These are just a couple of the ways that the latest CSS frameworks respond to those critics who complain about having to sacrifice HTML code quality to use them. Now you can have all the benefits of a well-tested layout framework, and apply them to your HTML code on your terms.

(photo: Nbauer)

  • madr

    When I first heard the phrase “CSS framework” my reaction was “Oh, for crying out LOUD!” since it from the beginning has taken the wrong approach: I agree with the Ninjas this article mention.

    I like this though. I believe the CSS frameworks are about to be redesigned to do good from another approach. SASS and LESS already works on the CSS-layer only, leaving the HTML clean and semantic, and it’s nice to see that Scaffold takes these strenths outside the rails community.

    I’m getting tired every time I set up conventions for a new project. It is way to hard and takes too long working in pure CSS, but I prefer that before writing tag soup.

  • Oyun

    thanks for this good information

  • I’ve only used a grid system for a couple of sites but didn’t bother using any of the default styles, but rather used the background PNG to create the layout and then when I knew how wide things were going to be, just used those widths in my stylesheet in conjunction with the classnames I chose like I normally would.

    I have been keen to give Scaffold a go but haven’t found the time to get around to it yet.

  • I’m one of the pragmatic ninjas. I’ll throw presentational stars in my HTML without much hesitation, rather than keeping to pure semantic but hard to maintain ninjutsu.

    Obviously, classes like “10pt-bold-red-double-border-box” are nonsense. Or even simple ones like “green”. But sometimes it’s easier to set up a few classes for common styles that may be used for very different content, and use those classes. If you have a sidebar with modules that have margin-tops of either 15px or 35px, it might be better to define a default of 15px, and a special class for when you need the bigger margin. So you could have <div class="module"></div> <div class="module module-bigmargin"></div>. If you have two or three different module styles with quite a few differences, you may want to use “module-style1”, “module-style2”, etc. If the only classes you’re using are “login”, “latest-comments”, “archives”, “tools” or whatever, you’re bound to fight with your own CSS when it comes to style “latest-comments” as a mix of “latest-articles” and “archives”. You will have to duplicate styles, or will use multiple selectors with commas (sometimes resulting in the styles of a specific element being scattered around).

    Also, i have found that when you do the front-end code for a client and their in-house developer takes over from there, there will be trouble because the designer didn’t think of everything and the developer will have to adapt your code to new content. If your classes are only semantic, you will end up with archives and articles with a “latest-comments” class, which defeats the purpose.

    Anyway, true HTML semantics are NOT in the classes. So-called “semantic” classes are just a workflow thing. It’s ok if it works, but when it actually makes your work or the work of others harder then you have a problem.

  • Obviously, if you’re using a CSS pre-processor then you may want to only use identifying classes (aka “semantic” classes) in your templates or static HTML, then in your CSS define some presentational classes and “call” them for your identifying classes. That’s one interesting worflow.

  • The end of CSS as we know and love it is nearly, along with HTML *waves*

  • Tim Kelty

    Don’t forget about! I’ve been using it for a while now and love it.

  • Brad Czerniak

    I’ve been trying to give away a great project starter sheet in my Hawidu CSS file, but nobody’s taken notice yet. You can paste in any layout you wish, but a headerless html5-based semantic layout comes out of the box.

    I’m especially proud of the forms. Buttons use a gradient overlay, so it’s a couple hex code changes to beautiful buttons in any color.

    Please use it!

  • Tigrish

    You should check out the Compass project which includes the blueprint and the frameworks. It’s built on top of SASS, and makes for rapid, semantically correct CSS. For me it’s the best solution available :

  • DAZ

    Since you can use as many classes as you like, why not just use both ‘semantic’ and ‘unsemantic’ classes?
    e.g. your sidebar takes up a third of the grid and has rounded corners – why not just use
    <div class="third rounded sidebar">

    You still get the (questionable) added semantic value of it being called ‘sidebar’ and don’t lose anything by having the extra classes there too.

    I actually think it is better practice to keep certain styles ring-fenced/encapsulated in their own class (for example the code used for rounded corners is not yet finalised so I’d prefer to keep it in its own class called ’rounded’ rather than have to edit lots of different classes if it changes).

    I blogged about this last year (

    I do like the look of LESS though – I’d like to see that notation incorporated into the CSS spec.

  • charlesroper

    Couple of points:

    First: Installing Ruby on Windows really isn’t a pain at all – just go to and you’ll be done in a couple of minutes. Truly, there’s no pain involved.

    Second: Compass is just as useful locally as it is as a server-side framework. In fact, I’ve never used it in a server-side context. If you use the “compass –watch” command, it watches your project and, as you edit your local sass files, it automatically compiles them, giving you instant feedback. It’s a blissful workflow that really deserves much more attention from the web design community. I mean, you get the holy grail of a CSS framework (actually, multiple frameworks – take your pick) that are semantic. You get a more powerful CSS (Sass 2.4 will be even more CSS-like, if you’re not fond of Sass in its current guise). It encourages best practise in the form of modularisation, resuse and readability. You can use it just as effectively locally as you can on the server.

    Not sold yet? Take a look at some deep-thinking on the problem-domain Compass and Sass are tackling at <a href=""Chris Eppstein's blog (he’s the author of Compass).

Get the latest in JavaScript, once a week, for free.