Design Frameworks

Sass, SCSS and Compass

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 home page:

  margin: 2em 0
    text-align: right

    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.


If you are interested in CSS, it might be useful to read up on the subject. The W3C's standard is at You also might be interested in HTML & CSS: The Good Parts, a book written by Ben Henick and published by O'Reilly that tries to point readers in the direction of useful and appropriate techniques. Another good O'Reilly book on the subject of CSS is the CSS Cookbook (3rd edition) by Christopher Schmitt.

Blueprint has not been updated since May 2011, but it still works and is well documented. You can read about it and download it from

Sass/SCSS is documented at The site includes many recipes for common things that people want to do. Compass, the framework built on Sass/SCSS, is at Note that many on-line tutorials and screencasts about Compass use the old Sass syntax and, thus, might be a bit hard to understand if you know only the new syntax.

Two books about Sass and Compass are Sass and Compass in Action by Wynn Netherland, Nathan Weizenbaum and Christopher Eppstein, published by Manning; and Pragmatic Guide to Sass, written by Sass creator Hampton Catlin, published by the Pragmatic Programmers.

Finally, if you are interested in comparing the finer points of Sass and LESS, a nice chart and introduction is at

Cube photo via


Reuven M. Lerner, Linux Journal Senior Columnist, a longtime Web developer, consultant and trainer, is completing his PhD in learning sciences at Northwestern University.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hey its wonderful.. really

tecsys's picture

Hey its wonderful.. really useful information. thanks

Never thought of this

Schoen's picture

Never thought of this "Blueprint" idea, and I must is very welcome. Thanks for the useful tip. Flexibility is great.

Reply to comment | Linux Journal

Tampa Family Lawyers's picture

Woah! I'm really enjoying the template/theme of this blog. It's
simple, yet effective. A lot of times it's challenging to get that "perfect balance" between usability and visual appeal. I must say you've done an
amazing job with this.Superb Blog! Gracias