The demise of plain CSS: Why Sass and languages like it will triumph

It is my opinion that these [tools like Sass] are only really of benefit to people who haven’t yet mastered writing CSS properly from the outset…

Harry Roberts (CSSwizardry.com)

Huh?

Sass only really benefits people who haven’t mastered writing CSS properly? Excuse me? I am a very experienced CSS developer and I find Sass quite valuable having written CSS for a living for many years now. While I won’t claim the level of mastery that an artist like Michelangelo achieved in painting, I can say that I wasn’t born yesterday either. I write all my CSS and HTML by hand. I haven’t used tools like Dreamweaver in nearly a decade.

I can only assume that Mr. Roberts has not done enough Sass to see the utility of the language. Perhaps he’s had to deal with someone else’s Sass or only muddled around with it for short period of time. At first glance Sass may seem like too much software, but in the hands of a competent designer it is truly wonderful. Having written Sass professionally for almost two years now I can say with confidence that Mr. Roberts is clearly missing something.

Sass – a programming language for designers

Sass is essentially a programming language for designers. It is extremely limited when compared with other languages, but it does a magnificent job of translating the core concepts of a programming language in a way that makes sense for styling a document.

Right now folks that use Sass primarily use it as a Rails plugin, but the Ruby gem also makes it possible to use it from the command line. This makes it easy to use Sass with any language (PHP, Python, even plain-jane HTML).

To use, you need to install the Haml gem. On a Mac you can do this from the command line like this:sudo gem install haml

This will the give you access to the sass command which you can use to generate CSS from Sass source files.

Nesting

So let’s talk about what I love about Sass.

At first blush, Sass looks like a better CSS. Instead of requiring you to repetitively list selectors, Sass allows you to nest selectors and rules:

form
  p label
    display: block
    font-weight: bold
  input.textbox
    background: white
    color: #666
  button
    color: white
    background: red
    padding: 10px 20px

The example above would generate:

form p label {
  display: block;
  font-weight: bold;
}
form input.textbox {
  background: white;
  color: #666;
}
form button {
  color: white;
  background: red;
  padding: 10px 20px;
}

Note the absence of brackets and semi-colons in the input. If this seems strange or ugly to you consider how many times a misplaced bracket or semicolon has caused a rule to render incorrectly. In practice, this bracket-less form of CSS keeps code clean and makes it much easier to write. Believe me. It may look strange at first but it leads to cleaner and less error-prone code. Of course, the code will be a lot easier to read if you use an editor with good syntax highlighting. (I recommend Textmate with the Sass bundle installed.)

But have no fear, if you prefer brackets, a future version of Sass will allow for a bracketed syntax as well (check out the scss branch).

The ability to nest rules is extremely powerful. Especially when you use it to combine selectors:

#content, #sidebar
  p
    margin: 1em 0

This would generate:

#content p, #sidebar p {
  margin: 1em 0;
}

The amount of typing that this can save is marvelous. Of course, all of this added power comes with a price. If you aren’t careful about your use of nesting and the comma operator you can generate a huge CSS file.

I’d recommend that you avoid nesting your rules more that three levels deep and that you use the comma operator sparingly. This will minimize the the number of lines in the output.

One day if Sass is supported by the browser this won’t be an issue, but as long as Sass is converted to CSS you will need to be conscientious about the output.

Variables

Another powerful feature that Sass borrows from programming languages is the concept of variables. Sass variables always begin with an exclamation point. Variable assignment looks like this:

!text_color = #666
!background = #f5f5f5

You can then use variables in your rules like this:

table
  color= !text_color
  tr.even td
    background= !background

Note the use of the = operator on the color and background rules. This is necessary so that Sass knows that you are using a calculated value for a rule. (In this case, a variable.)

The above would generate the following CSS:

table {
  color: #666;
}
table tr.even td {
  background: #f5f5f5;
}

Sass even allows you to do math on variables. Need a darker gray for odd rows? No problem:

table tr.odd td
  background= !background - #333

Output:

table tr.odd td {
  background: #c2c2c2;
}

Variables can store font names, numbers, colors, you name it. If you can write it in CSS you can store it in a variable.

Mixins

This brings me to my favorite thing about Sass: mixins. Sass mixins are the stylesheet equivalent of functions. They allow you define a series of rules which can be mixed in to another ruleset with ease.

Here is an example of a simple clear fix mixin:

=clearfix
  overflow: hidden
  display: inline-block

This mixin can then be applied to a ruleset like this:

#content
  +clearfix

Which would generate:

#content {
  overflow: hidden;
  display: inline-block;
}

Mixins can also accept arguments. Here is one of my favorite CSS3 mixins:

=round-corners(!amount)
  border-radius= !amount
  -moz-border-radius= !amount
  -webkit-border-radius= !amount

This would allow you to write:

.box
  +round-corners(5px)

Which would output:

.box {
  border-radius: 5px;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
}

But mixins aren’t just about limiting the amount of typing that you have to do to create a certain effect. I have mixins for default form styles, base typography, resetting a stylesheet, etc… Mixins give you the ability to build a reusable library of styles that you can incorporate into your projects as needed.

It is important to note that mixin definitions do not impact the CSS output unless they are used in a ruleset. This means you can have potentially hundreds of mixins defined and only use a couple of them on a given project. For the first time it is now possible to build a viable CSS framework. (Compass is a powerful example of this.)

Other features

There are a number of other features that Sass offers that make it a formidable tool in the designer’s arsenal, but these are features that I love. If you want familiarize yourself with all of Sass’s loveliness, I recommend reading the Sass Reference.

A little programing history

Now, it is my opinion that one reason designers have been slow to embrace languages like Sass is that these languages appeal to people that think more like programmers than designers. Programmers have almost made code simplicity an art form while designers are known for spending vast amounts of time doing very tedious and repetitive work to get the effect that they want. Thankfully, this is not always the case with web developers, but in this case we are still a bit behind the curve.

Programmers haven’t always been this way. There was a time when programmers stuck to assembler like a new born babes cling to their mommies. They objected to the output of compilers and preferred writing assembler by hand. (Sound familiar?). They could write better assembler themselves they said. They didn’t need the productivity boost that higher level languages offered. They were just fine thank you.

And then something marvelous happened. Compilers got to the point that they were able (as a general rule) to produce more efficient assembler than most coders could by hand. With compiled languages, people found that they were able to tackle more complicated programming work because they could think less about the machine and more about the problem they were trying to tackle.

Surprisingly, it was assembler that got the boot as higher-level languages began to dominate.

And this trend in programming has continued. Interpreted languages like Ruby, Python, Perl, and yes, even PHP, are now replacing compiled languages. I am not saying that the need for compiled languages will be completely eliminated by interpreted languages, but it is clear that as computers have gotten faster the need for compiled code (for many applications) is diminishing. (Yes I am aware Ruby, Python, Perl, and PHP can now be compiled, but they will always retain their dynamic, uncompiled heritage.)

Programmers are used to this kind of progress. Every couple of years the dominant programming language is replaced by another. Code is getting leaner, meaner, and easier to understand.

The moral of the story

Does anyone else spot the trend here? Just like higher-level programming languages compile to assembler, so Sass compiles to CSS. And just as higher-level programming languages eventually replaced the regular usage of assembler, so Sass (or a language like it) will eventually replace CSS.

Now, don’t get me wrong. I am sure CSS has many more years ahead of it, but Sass and languages like it are the future. Yes, you can complain about the syntax. You can complain about the generated code. But ultimately, the productivity and simplicity that languages like Sass offer will win over the masses. Of that you can be sure.

One day, Sass (or a language like it) will be more common than CSS.

Update! Based on feedback I’ve tweaked the title of this post a little. The original title began, The Demise of CSS: Why Sass… Apparently, some people thought I was saying that Sass would replace CSS. While that may happen, it is probably more likely that features of Sass will be incorporated into CSS. Either way CSS will certainly remain in one form or another. Sass doesn’t replace CSS. It adds a cleaner syntax and additional functionality.