At the Forge

For as long as I can remember, I've known how to use a pencil. I can write with it, and I even can draw with it—although in my case, saying I can draw is something of a sad exaggeration. I might know how to use a pencil and thoroughly understand its technology, but that technical knowledge doesn't mean I can draw something aesthetically pleasing.

I mention this because I always think of my poor drawing abilities when I work with CSS. I understand the technology and have used it for many years. I'm comfortable working with and modifying stylesheets, and using complex selectors. And yet, any Web application that I create on my own looks ugly. Despite all of my technical knowledge of CSS, I'm generally unable to make a nicer, more pleasing design.

Fortunately for people like me, a new type of framework exists to help with such problems. Just as server-side frameworks like Ruby on Rails and Django make it easy to create Web applications, and client-side frameworks like Backbone.js and Knockout.js make it easy to create in-browser applications, design frameworks make it easy to decorate and design your applications.

Now, when I first heard about design frameworks (sometimes known as CSS frameworks), I wondered how they could possibly help. After all, I already know CSS; what could they contribute? The answer is: a great deal. By embracing a design framework, you gain a number of CSS classes and IDs that make it very easy to lay out your page. By choosing the right classes, you can make a site look more than reasonable, even if you have my graphic design skills. Using a design framework means that even if you don't have any design skills, you can make a site that looks fairly pleasing. If you do have design skills, the framework will allow you to do more with less effort.

In this article, I describe some of the leading design frameworks, leading up to the latest and most interesting one, Twitter's Bootstrap. In my next article, I'll look more closely at Bootstrap and why it has taken the world by storm.

The first design framework I'm aware of was (and is) Blueprint. The idea behind Blueprint is pretty simple. You download and refer to Blueprint's three CSS files: one for the screen, one for print and one with special definitions for Internet Explorer:

<link rel="stylesheet" href="css/blueprint/screen.css" 
 ↪type="text/css" media="screen, projection">
<link rel="stylesheet" href="css/blueprint/print.css" 
 ↪type="text/css" media="print">
<!--[if lt IE 8]>
   <link rel="stylesheet" href="css/blueprint/ie.css" 
 ↪type="text/css" media="screen, projection">
<![endif]-->`

By including these stylesheets, Blueprint resets the CSS values for the user's browser, removing any defaults that might have been set elsewhere for margins, padding and borders.

Blueprint also resets the defaults for typography, ensuring that your headline and paragraph tags look better, and more consistent, than the defaults defined by each browser. Again, even without any additional effort on your part, Blueprint ensures that your typography is a bit more in line with established principles of design. As the Blueprint Web site says, these principles predated the Web and still are relevant in our electronic age.

The real magic of Blueprint, however, is in its layout. Blueprint offers a “grid layout”, which in practical terms means it provides you with CSS classes that let you indicate how wide a particular element should be, from one column across to 24 columns across. Do you want to display two divs, side by side, with the left-hand div taking up two-thirds of the space? No problem—just define them as follows:

<div class="container">
    <div class="span-16">This is the left-hand div</div>
    <div class="span-8 last">This is the right-hand div</div>
</div>

By using these CSS classes, the divs automatically will take up the right amount of space on a user's screen. Moreover, because the content is inside a div named “container”, the width of the screen (and of the divs) will adjust automatically according to the width of the user's browser window.

Before Blueprint, Web designers would do all this work themselves, implementing and re-implementing such columnar layouts on their own, specifically for each site. The advantage of Blueprint's 24-column grid is that you have enormous flexibility in the layout of your pages, letting each element extend across however many columns you think are appropriate. So long as the span-* classes add up to 24, and the final element on each row has the “last” class, the layout will look pretty good. This is far better, in every way, from what many people would do to ensure a certain layout, namely the use of tables. Tables are great, but not for laying out a page. I can't tell you how many times I've seen tables triple-nested inside other tables, just to get the layout to work appropriately.

Another advantage of Blueprint is that it has tried and tested these CSS definitions on a variety of browsers. You no longer need to worry about whether things will work on Chrome, Firefox, IE and Safari, because Blueprint has taken care of that for you. The special IE-only CSS file ensures that Internet Explorer also will work correctly, even if your users are running an old version.

Of course, because Blueprint is a bunch of CSS files, you always can change it to suit your needs. And indeed, much of the (extensive) Blueprint documentation describes how you can customize not only the layouts, but also the CSS itself.

The biggest criticism of Blueprint is that its class names violate the spirit of CSS. Sure, you can have classes named “span-5” and “span-10” to indicate that you want text to extend across five or ten columns of your 24-column layout. But, wasn't CSS supposed to free you from such calculations, allowing you to think more in terms of semantic names? My response is that, yes, this is a good point, but Blueprint's layouts are so useful and so easy to understand, it's unhelpful to focus on the original intent of CSS's designers.

Another problem with Blueprint isn't inherent to Blueprint itself, but rather to the technology on which it's based. CSS is a very clever technical standard, but it has been demonstrably difficult for people to learn and understand, and also for many designers to use. True, some people are able to make beautiful, clever designs with CSS, and I don't mean to diminish their capabilities in any way. But, CSS has a number of deficiencies, many of which I hadn't thought about until I discovered Sass a few years ago.

Sass (Syntactically Awesome Stylesheets) is a CSS preprocessor. That is, it is a file format that you compile, with the output of the compilation being a CSS file. Sass has a large number of advantages over straight CSS, starting with the fact that you can set variables. This is a tremendous thing when you're creating a site that should have a consistent color scheme. You can set the colors in one place and then use them in many different places.

Sass also lets you nest CSS definitions, such that if you have several elements that share definitions, you no longer have to repeat those similarities in different places, but can take advantage of something akin to variable scoping in a programming language. Nesting also means that complex selectors become easier both to write and to read, since they break the path down into digestible parts.

Sass also offers a type of function or macro definition, known as a “mixin”, allowing you to keep your CSS DRY (“Don't Repeat Yourself”). This means you can define a CSS rule in one place and then include it in multiple other places.

Now, Sass has been around for several years, and it has worked well during that time. It originally was written by developer Hampton Catlin (who also developed the Haml template format), but has since been taken over by Nathan Weizenbaum and Chris Eppstein. The original Sass syntax resembled Python in some ways, in that trailing semicolons were removed and indentation was a mandatory part of the syntax. That is, the indentation of your declaration, or even of the definition of your mixin, mandated indentation, and the level of indentation reflected the scope within which your definitions would take effect. For example, here is a simple set of definitions in Sass, taken from the sass-lang.com home page:

table.hl
  margin: 2em 0
  td.ln
    text-align: right

li
  font:
    family: serif
    weight: bold
    size: 1.2em

You then would run a Sass compiler over the Sass file, producing a CSS file that could be interpreted by a Web browser.

This syntax still exists, and if you prefer it, Sass happily will work with you. However, the preferred syntax is now known as SCSS, and it is a superset of the existing CSS syntax. My impression is that the syntax changed partly because the differences between CSS and Sass were too great for many people, and the mandatory indentation caused problems for a number of users. Thus, the Sass shown above can be expressed in SCSS as follows:

table.hl {
  margin: 2em 0;
  td.ln {
    text-align: right;
  }
}

li {
  font: {
    family: serif;
    weight: bold;
    size: 1.2em;
  }
}

As you can see, the syntax is quite similar to that of standard CSS, making it easier for people to make the transition from CSS.

The entire Sass framework, including both syntaxes, is mainly implemented in Ruby and is in widespread use among Ruby-language Web developers. However, you aren't required to use Ruby as your Web development language. Many people use this system, compiling it from Sass/SCSS into CSS without knowing or caring that they're using Ruby. That said, the Ruby on Rails framework has adopted SCSS as a standard part of its infrastructure, such that anyone using Rails likely will know and use it.

Neither Sass nor SCSS is a design framework; they are stylesheet languages and are meant to simplify your CSS development. But the authors of Sass have created the Compass design framework (which they call a “CSS authoring framework”), which predefines a large number of classes and mixins for use in your own projects. So if you want to have rounded corners or standardized fonts or a set palate of colors, Compass will make it easy for you to do so.

Moreover, Compass comes with a Blueprint compatibility mode. This means if you have a site that already is working with Blueprint, you can (mostly) just replace the Blueprint CSS files with the Compass CSS files, and you're done.

Compass is both clever and powerful, and I'm very impressed with what I have seen and how it works. Nevertheless, I have been disappointed with its level of documentation, especially on issues having to do with the Blueprint compatibility. Yes, I was able to find all the answers I wanted in the end, and the e-mail list is particularly active and helpful. But I was surprised by how much I had to turn back to the Blueprint documentation to understand what the Compass compatibility mode was doing, rather than just being able to access the documentation directly.

None of this takes away from the power Compass provides and the flexibility it offers users. If you're interested in working with Compass, and not just with Sass/SCSS, either of the books that I mention in the Resources section probably will be useful, given the detail in which they describe the Compass framework.

LESS is another stylesheet language, and it's very similar in many ways to the SCSS syntax from the Sass framework. Indeed, my impression is that SCSS and LESS learned from and influenced one another, although it's not clear to me just who influenced whom, and at what times. The bottom line is that if you're comfortable with SCSS, you're likely to be comfortable with LESS, and vice versa. There are some differences in the syntax, but they're pretty minor.

One difference between LESS and Sass is that LESS files can be compiled in a number of different ways. They can be turned into CSS using a compiler—originally written in Ruby, but currently written in JavaScript—running on the developer's computer, either before or during the deployment process. However, because the implementation is in JavaScript, another option is available. You can download the LESS stylesheet, as is, into your browser and then use a JavaScript library to translate it into CSS on the fly. For example:

<link rel="stylesheet/less" type="text/css" href="styles.less">
<script src="less.js" type="text/javascript"></script>

For performance reasons, it's best to compile the LESS file into CSS beforehand. However, this is useful when the compiler is not available, if you want to generate stylesheets dynamically, and also during development.

Why would you prefer LESS over SCSS, or vice versa? I honestly cannot give a compelling reason for one over the other. They're so similar and have such advantages over plain-vanilla CSS that it doesn't matter which you choose, so long as you go with one of them. Before Bootstrap, I would have put my money on SCSS becoming the de facto standard, but Bootstrap might have given LESS a new lease on life, and might even help it overtake SCSS.

Given the similarity between LESS and SCSS, I'm not surprised a framework emerged that is based on LESS. But the framework that was created (Bootstrap, written by two engineers at Twitter and released under the Apache license) has turned out to be a huge hit among developers and designers alike. Bootstrap not only includes Blueprint's grid, but also a large number of other conveniences and stylings that make it easy to have good-looking navigation bars, tables, forms and even widgets for dynamic, client-side applications. Bootstrap even is capable of modifying the size and shape of menus depending on screen size, making it a “reactive” framework appropriate for mobile devices as much as desktop computers.

Some people even are getting tired of Twitter Bootstrap, because it has become so popular and makes it easy to create designs that look like many other Bootstrap sites. But for someone like me, who just wants to get a simple site up and running, and for it to be relatively nice-looking, I've found Bootstrap to be a huge help.

In my next article, I'll actually look at Bootstrap—what it provides, how to install and use it, and even how to use it along with Ruby on Rails, which (as I mentioned above) comes with support for SCSS, rather than LESS. Regardless of which of these systems and frameworks you use though, I strongly encourage you to try them and incorporate them into your own work. An experienced designer presumably will know how to integrate these technologies, while design-challenged programmers will welcome the chance to create a nice-looking site on their own.