Syntactically Awesome Stylesheets

DZone 's Guide to

Syntactically Awesome Stylesheets

· Web Dev Zone ·
Free Resource

SASS is a layer of abstraction over CSS 3 style sheets, with a rationale similar to CoffeeScript's one. It is a more powerful language, which compiles to CSS 3; it's built starting from the CSS syntax and adding constructs, in the same way as old style PHP code was submerged into HTML pages.

Thus, a .css file is already a valid SASS file. However, SASS stylesheets are identified by the .scss extension, which is truncated to .css during compilation.

Note that in this article we will refer to the SCSS newer syntax, not the older ruby-like one. This syntax has the primary support from the tool, and retains compatibility with .css.


The sass binary is installable with a Ruby library (libhaml-ruby1.8 in Ubuntu) on Linux. Compilation is really easy:

sass style.scss:style.css

tranforms style.scss into the style.css CSS file.

sass --watch style.scss:style.css

does the same, and does not exit. Instead, it listens for modifications on style.scss to recompile when needed.


The markup this code works on are two simple block elements, each with a contained span.

    <link rel="StyleSheet" type="text/css" href="style.css" />
Lorem ipsum dolor <span>sit amet</span>...
Lorem ipsum dolor <span>sit amet</span>...

These examples are just a selection of the most important features, and the SASS documentation may help you discovering more. But when designing a new layer of abstraction, the question is what not to include, and SASS seems oriented to provide the best 80% of functionality.


Selectors can be nested, in order to easy locate rules that apply to children elements.

p {
    span {
        color: #006699;

Nesting can also be applied to properties: border and its derivates are ideal to demonstrate this, as the sass manual shows:

    border: {
        color: black;
        style: solid;
        top: {
            width: 10px;
        left: {
            width: 5px;



Variables can be defined and then reused throughout the file, just like PHP or JSP variables in the page scope. Finally we get a "DRY" solution, since CSS is based only on inheritance and has to inherit a property from a more general selector everytime it needs to share a value.

$textColor: blue;
$highlightedColor: navy;

p {
    color: $textColor;
    span {
        color: $highlightedColor;



Think of mixins just as the inclusion of another, smalle file inside a selector.

@mixin readable-font {
    font-size: 16px;
    font-family: Verdana, sans-serif;

    @include readable-font;
    background-color: #006699;

Self-explanatory, right? Mixins can also take parameters, so in that case they're more like functions (View Helpers, precisely) than plain old files.


SASS, just as CoffeeScript, is an innovation that takes place on the server-side: there is more freedom of what you can install there due to lower and lower costs of servers. Browsers are the bottleneck where new technologies cannot be deployed shortly.

You can always preprocess the files on deployment and only upload .css to the server, just as with coffeescript; you can also compile inside your web framework or not write anything to disk (after all, a PHP view is not written to disk when it's rendered.)

The language is mostly backward compatible, like in the case of PHP into HTML pages. It's as easy as pie: you can easily understand the language (but not write it ex novo) even if you have had no exposure to it beforehand. But the question is always the same: will the gains from the superior language outweigh the costs from the additional compilation step and tooling maintenance?


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}