Often cited as one of the biggest missing features of CSS, variables can be very powerful and very useful. You can use variables to store any piece of information you expect to use multiple times and define it in one place. This means that changing this definition once will affect every instance in which we have used the variable. This is a very efficient and robust way of working. Any variable in LESS is prefixed with the @ symbol. Declaring variables in LESS is as simple as stating the name, a colon, the value, and a semicolon to end the line. Since the variables will never reach the final parsed CSS, the rules about which characters you can use are much simpler; you are building for one parser instead of many browsers.

Variables cannot be set again and again (they are not variable!^[86]). In fact, variables in LESS are constants. It is a common programming convention to use all caps for constants with underscores as word delimiters, and makes it very easy to visually locate the variables within your LESS files, but you should use whatever naming convention you and your team find most appropriate (many prefer to stick to CSS-like formats). Here's a basic example of variable usage:

@PRIMARY_COLOR: #faa344;

#content {color: @PRIMARY_COLOR;}

This, when compiled, emits the following:

#content {
  color: #faa344;
}

As you can see, LESS has its own ideas of how CSS should look: multiline indented with two spaces, and no vertical gaps between rules. Since the idea is that you would be developing primarily in LESS, the formatting of the output is of far less importance.

You can reuse your variables as many times as you like. LESS also understands the concept of scope, which means that you can declare the same variable in different contexts and have the value change only for that context. Any variable at the top level (outside of any selectors) is of global scope. Any variable declared inside a selector has that selector as its scope. A variable only exists within its scope and overrides any variable of wider scope. When referencing a variable, LESS will look within the scope local to the reference and then work its way up the chain to the global scope, using the first value it comes across. This might be easier to understand with an example.

This LESS:

@PRIMARY_COLOR: #faa344;

#content {
   @PRIMARY_COLOR: red;

color: @PRIMARY_COLOR;
}

#footer {
   color: @PRIMARY_COLOR;
}

...compiles into the following:

#content {
  color: red;
}
#footer {
  color: #faa344;
}

The first declaration of @PRIMARY_COLOR is outside any selectors; it is in global scope. The second declaration is in the context of #content. At this point, it overrides the first declaration, since that declaration has wider (less specific) scope. The second declaration only lives for as long as its context lives, so as soon as we close the braces for #content that variable is discarded, and we are left with our initial declaration instead. Where the same variable is declared multiple times in the same scope, all declarations but the first are ignored.

You can output multiple variables in one property by space-separating them, like this for the LESS:

@VERTICAL_MARGIN: 10px;
@HORIZONTAL_MARGIN: 15px;

#content {
   margin: @VERTICAL_MARGIN @HORIZONTAL_MARGIN;
}

It outputs the following:

#content {
  margin: 10px 15px;
}

But there is no current way to concatenate strings together—leaving no space results in LESS adding a space on your behalf. To demonstrate:

@VERTICAL_MARGIN: 10px;
@HORIZONTAL_MARGIN: 15px;

#content {
   margin: @VERTICAL_MARGIN@HORIZONTAL_MARGIN;
}

In this code, we removed the space between the output variable, but the result is the same:

#content {
  margin: 10px 15px;
}

In addition to colors, variables in LESS can really represent anything we might use as or within a value in CSS, from strings of text to numbers.

A mixin is a piece of code that is easy to reuse in another place. You could consider it similar to a function or method in JavaScript, or a way of inheriting properties from another CSS rule. Using mixins, it is possible to use a CSS rule within another. By using just the selector from a previous rule within another, all the properties from the referenced rule will be included.

This LESS:

.callToAction {
   color: #123;
}
#content {
   .callToAction;
}

...results in this CSS:

.callToAction {
  color: #123;
}
#content {
  color: #123;
}

It is worth noting that the original rule still exists in our outputted CSS. If you just intended this to be a reusable block of code that did not target any elements on its own, this would not be as efficient as you might like and would make for extraneous code in the output.

You can also use mixins in a similar fashion to functions or methods. This means you can pass values into a mixin and also have defaults for when nothing is passed. LESS calls these parametric mixins. To indicate that a mixin accepts parameters, you can follow it with brackets, with the names of the variables within the brackets. The variables should be comma-separated if there are more than one, and each should be followed with a colon and their default values if appropriate. For example, this LESS:

.box (@HEIGHT: 40px, @WIDTH: 40px) {
   height: @HEIGHT;
   width: @WIDTH;
}

#content {
   .box(20px,80px);
}

.callToAction {
   .box;
}

...compiles into this CSS:

#content {
  height: 20px;
  width: 80px;
}
.callToAction {
  height: 40px;
  width: 40px;
}

As you can see, this method has the added benefit of no longer outputting the mixin in our code! If we are aware of this, we can use this trick to make mixins that require no parameters to no longer appear in our output just by following their name with empty brackets, like so:

.callToAction () {
   color: #abc;
}

#content {
   .callToAction;
}

Which results in this CSS:

#content {
  color: #abc;
}

This method won't work with selectors more complicated than a single class name or ID, so you can't define a mixin with, for example, a tag name or descendent selector—it will cause an error. LESS is clever enough to know that any selector that contains no properties (or only variables) will not be outputted in the compiled CSS.^[87]

Not specifying defaults, in effect, makes those arguments "required." If you reference a mixin that has no defaults set, and you don't pass values to it, this will cause an error.

Mixins are particularly useful for abstracting away experimental properties that are yet to be finalized in the specification. They are likely to have slightly different and convoluted syntaxes for different browsers and use vendor prefixes to separate them. Keeping these properties in separate modules makes them easy to amend as the specification and support changes, and have these changes reflected in the entirety of your code while minimizing human error and removing the need to write every vendor-specific version out each time you use it.

It is possible to nest rules within one another and for LESS to work its way up the chain of selectors to build the eventual selector for CSS. Again, an example:

#content {
   .callToAction {
      a {
         color: #321;
      }
   }
}

And the result:

#content .callToAction a {
  color: #321;
}

This is at the same time a blessing and a curse. By indenting and nesting, it is really easy to emulate the structure of our HTML, which can be a very intuitive way to work. However, the resulting selectors can be verbose and specific, which is unlikely to be the resulting CSS we had intended for. Here's a more complex example:

#content {
   .callToAction {
      a {
         color: #111;
      }
      p {
         color: #111;
      }
      div {
         color: #111;
      }
   }
}

And the result:

#content .callToAction a {
  color: #111;
}
#content .callToAction p {
  color: #111;
}
#content .callToAction div {
  color: #111;
}

Not only is this CSS more specific than it probably needs to be but it also could have been accomplished more efficiently with multiple comma-separated selectors, like so:

#content .callToAction a, #content .callToAction p, #content .callToAction div {
  color: #111;
}

This method also encourages you to write CSS specific to certain elements rather than reusable classes, which is an inefficient way of writing CSS. Unless you are using this method to group mixins or variables (covered later in the "Namespaces" and "Accessors" sections), or you are using a class name or ID as a namespace, we do not recommend using nested rules in this way.

It is possible to mix nested rules and properties, like so:

#content {
   position: absolute;
   p {
      color: red;
      a {
         color: blue;
      }
   }
}

And the result is the following:

#content {
  position: absolute;
}
#content p {
  color: red;
}
#content p a {
  color: blue;
}

You can also nest pseudo-classes, which is a great use for this feature. By simply including the colon and the pseudo-class, you can generate several lines in one go. The uncompiled LESS:

a {
   :hover {
      color:blue;
   }
   :visited {
      color:red;
   }
   :link {
      color:green;
   }
   :active {
      color:yellow;

}
}

...and the resulting CSS:

a :hover {
  color: blue;
}
a :visited {
  color: red;
}
a :link {
  color: green;
}
a :active {
  color: yellow;
}

You can also use the & combinator to output the entire selector within your nested rules, and properties. This is particularly useful for chaining class names:

#content {
   .callToAction {
      color: red;
      &.disabled {
         color: gray;
      }
   }
}

Results in:

#content .callToAction {
  color: red;
}
#content .callToAction.disabled {
  color: gray;
}

However, if you try to use the & combinator to place the parent selector after the current selector, LESS will rearrange those selectors:

#content {
   body & {
      color:blue;
   }
}

It becomes the following:

#content body {

color: blue;
}

This is almost certainly not your intent (you would expect the selector to be body #content). Provided that you understand the potential negative impacts of nested selectors, they can be very useful.

LESS allows us to perform basic mathematical operations on values and have those evaluated before outputting the CSS. The operations available are addition, subtraction, division, and multiplication (there is no modulus operator). Here's a quick example of these in action:

@BORDER_TOP: 1 + 1;
@BORDER_RIGHT: 1 - 1;
@BORDER_BOTTOM: 2 * 2;
@BORDER_LEFT: 6 / 2;

.callToAction {
   border-top:@BORDER_TOP;
   border-right:@BORDER_RIGHT;
   border-bottom:@BORDER_BOTTOM;
   border-left:@BORDER_LEFT;
}

The result is the following:

.callToAction {
  border-top: 2;
  border-right: 0;
  border-bottom: 4;
  border-left: 3;
}

It is important that the operator (+ or -) has a space before and after it (other whitespace characters cause errors), or else the results can be somewhat unpredictable when performing operations on variables. LESS can also apply these operators to units. Only one unit needs to be present in the equation, and LESS will assume that unit for all others. Trying to perform calculations with multiple units will cause an error and will fail to compile.^[88] Here's an example:

@BORDER_TOP: 1px + 1px;
@BORDER_RIGHT: 1 - 1px;
@BORDER_BOTTOM: 2em * 2;
@BORDER_LEFT: 6 * 20%;

.callToAction {
   border-top:@BORDER_TOP;
   border-right:@BORDER_RIGHT;

border-bottom:@BORDER_BOTTOM;
   border-left:@BORDER_LEFT;
}

The result is as follows:

.callToAction {
  border-top: 2px;
  border-right: 0px;
  border-bottom: 4em;
  border-left: 120%;
}

Note that % is treated as a unit, and does not act as a modulus operator^[89] nor is it used to find a percentage of the other value in the calculation. Note also that LESS continues to append the unit even for values of zero (where it is unnecessary) when using its built-in compression, but an additional minification script could remove this.

You cannot perform operations on simple string values, but LESS is clever enough to perform calculations like this on colors (including HSL and HSLA colors), although it converts them to hex. Actually, the current version even converts RGBA and HSLA colors to hex when using them within calculations, losing the alpha channel altogether, so we recommend against this. The author has promised this will be fixed in the next release. It is not possible to perform calculations against a named color because LESS would treat it as a string of characters, not as a color—in fact with the addition operator, LESS attaches the named color after the first with a space, which is very unlikely to be your intended result. When using colors in calculations, LESS breaks them into their components, evaluates the calculation against each component, and then reattaches them. You can even use more than one color in a calculation, and LESS will evaluate the red, green, and blue channels independently (or hue, saturation, and lightness). It is also possible to use variables within operations. Again, here's an example:

@BORDER_TOP_COLOR: #aabbcc / 2;
@BORDER_RIGHT_COLOR: @BORDER_TOP_COLOR + #111;
@BORDER_BOTTOM_COLOR: rgb(13,26,39) * 2;
@BORDER_LEFT_COLOR: rgba(10,20,15,0.1) + @BORDER_RIGHT_COLOR;

.callToAction {
   border-top-color:@BORDER_TOP_COLOR;
   border-right-color:@BORDER_RIGHT_COLOR;
   border-bottom-color:@BORDER_BOTTOM_COLOR;
   border-left-color:@BORDER_LEFT_COLOR;
}

And the compiled code is the following:

.callToAction {
  border-top-color: #555e66;
  border-right-color: #666f77;
  border-bottom-color: #1a344e;
  border-left-color: #708386;
}

As you can see, the entire alpha channel for @BORDER_LEFT_COLOR has been lost. You need to be aware of this impediment when using operations with colors.

You can employ these methods to lighten or darken colors, and use a single primary variable to create shades of that color. This is a very powerful method for generating color schemes based upon only a few initial colors.

Newly introduced in LESS, some built-in functions exist for manipulating color:

For each of these, LESS will convert the color to the HSL color-space before applying the transformation. It will then convert the color back to hex for the result, unless the opacity is less than 100%, in which case it will convert it to RGBA. Here's an example of these color functions in use:

@COLOR: #aabbcc;
@COLOR1: lighten(@COLOR, 10%);
@COLOR2: darken(@COLOR, 10%);
@COLOR3: saturate(@COLOR, 10%);
@COLOR4: desaturate(@COLOR, 10%);

@COLOR5: spin(@COLOR, 10);
@COLOR6: spin(@COLOR, −10);
@COLOR7: fadeout(@COLOR, 50%);
@COLOR8: fadein(@COLOR7, 25%);

a {
   color: @COLOR;
   :link {
      color: @COLOR1;
   }
   :visited {
      color: @COLOR2;
   }
   :hover {
      color: @COLOR3;
   }
   :active {
      color: @COLOR4;
   }
   .callToAction {
      :link {
         color: @COLOR5;
      }
      :visited {
         color: @COLOR6;
      }
      :hover {
         color: @COLOR7;
      }
      :active {
         color: @COLOR8;
      }
   }
}

And the result:

a {
  color: #aabbcc;
}
a :link {
  color: #cad5df;
}
a :visited {
  color: #8aa2b9;
}
a :hover {
  color: #a3bbd3;
}

a :active {
  color: #b1bbc5;
}
a.callToAction:link {
  color: #aab5cc;
}
a.callToAction:visited {
  color: #aac1cc;
}
a.callToAction:hover {
  color: rgba(170, 187, 204, 0.5);
}
a.callToAction:active {
  color: rgba(170, 187, 204, 0.75);
}

This is a great demonstration of how a single color can be used to generate an entire color scheme. There are also built-in functions to extract the individual HSL channels called (predictably) hue(), saturation(), and lightness(). You can use these functions to build colors based upon the channels of other colors. Any of these functions can be combined with others. Here's an example:

@COLOR1: #123;
@COLOR2: #456;
@COLOR3: #789;
@NEW_COLOR: lighten(hsl(hue(@COLOR1),saturation(@COLOR2),lightness(@COLOR3)), 10%);

a {
   color: @NEW_COLOR;
}

And the result, with our new color, is the following:

a {
  color: #8ea1b4;
}

It is possible in LESS to group properties together in nested mixins (namespaces) and reference those properties as groups by using the > character. This can be useful for encapsulating and keeping code tidy. As always, this is easiest to demonstrate with examples:

#box () {
   .square {
      width:80px;
      height:80px;
   }
}

.content {
   #box > .square;
}

...and the result:

.content {
  width: 80px;
  height: 80px;
}

This technique can be very useful, although it has been somewhat crippled since earlier versions of LESS, in which you could access individual properties and variables within namespaces. It is possible to nest namespaces as many levels deep as you like.

LESS also enables C-style, single-line commenting as well as block commenting, however only CSS style comments are outputted in the compiled CSS unless you are using the built-in minification. Here's a quick example:

/*
A regular CSS block level comment:
*/
#content {
   color: black; //A single line C-style comment
}

And the result:

/*
A regular CSS block level comment:
*/
#content {
  color: black;
}

LESS supports the @import directive to directly include files within others. You can include CSS files or LESS files in this fashion. When including LESS files, the file suffix is not necessary. For this example, we'll need to demonstrate the contents of several files:

@import "style2";

#content {
   color: red;
}

footer {
   color: red;
}

@import "style3.css";

header {
   color: red;
}

Compiling style.less now results in the following:

@import "style3.css";
footer {
  color: red;
}
#content {
  color: red;
}

This method is very useful for keeping features separate. Any variables or mixins declared in any of the LESS files are available to others, including that one. This makes it easy to create, for example, a single configuration file of variables used to drive the rest of the LESS code. It is important to remember that building that configuration file would result in an empty CSS file because there would be no standard CSS code within it. You must always compile the lowest-level file that includes the others to build the correct CSS. This means compiling that file even though there are no changes to it.

Using the included compiler is just one way you can create CSS files from their LESS counterparts. If you are using node.js, the node package can be used directly within your node.js applications.^[90] For those who prefer a graphical user interface (GUI) to the command line, an application called Less.app is available for OSX at http://incident57.com/less/, which has the ability to watch folders or files, and automatically compile (see Figure 9-4).

Figure 9-4. LESS.app version 2.3.1

There are also plugins for popular IDEs, text editors, and web frameworks such as Apache, Grails, PHP (http://leafo.net/lessphp/), and .NET (http://www.dotlesscss.org/). Using these plugins can make it possible to have LESS compiled for you at read-time (when the user tries to access the file), so you need not compile manually, and caching avoids performance worries.

Unfortunately, there are downsides to LESS. Although easy to learn, there are few developers out there who are familiar with LESS. You need to implement it strictly and educate your developers: any developer accidentally modifying CSS code directly will lose changes with the next compilation. The nested rules (for example) can make it difficult to control the specificity of selectors. And, worst of all, when trying to debug your CSS in Firebug or any other web inspector, the files you are inspecting (the outputted files) will not relate to your source files in any intuitive fashion (line number will not match, selectors may not appear the same, and so on) unless you are using LessPHP.

Also, the code and behavior have been modified dramatically between versions, with no change log or documentation explaining what has changed or how to modify your existing code to cope with these changes. If you are using a port of LESS such as LESS.app, LessPHP, or .Less, the interface and code can differ greatly between versions because the port will need to be updated with each code revision and may take a while to catch up. Read "Evaluating Third-Party Preprocessors" later in this chapter for more information on how these critiques can apply to any third-party code you use in your development process.

That said, LESS is an attractive and fun way to write CSS. However, the issues we have mentioned make it very difficult for us to recommend it for a production system; if functionality and implementation changes so severely with no recorded justification and bugs creep into the system, it indicates there is no kind of regression testing taking place—this is not the sort of thing you want to be beta testing on a high-traffic website. Read more about LESS at the official website http://lesscss.org/.

Variables use a slightly different syntax in Sass. Originally, creating variables used the following syntax:

!variable = value

Since the move to a more CSS-like syntax, this is deprecated. The new style is similar to LESS, but uses a dollar symbol as the prefix:

$variable: value;

Sass also gives you the ability to include variable values directly in the output (known as "interpolation"), which allows you to concatenate variables or even use them in selectors. This is achieved by surrounding the variable name with braces and prefixing it with a hash symbol. The following SCSS:

$id: product;
$property: color;
$value: green;

#content .#{$id} {
   #{$property}:#{$value};
}

...compiles to the following:

#content .product {
  color: green; }

This makes variables a lot more versatile in Sass than in LESS. By default, Sass also always formats the output on multiple lines, indented with two spaces, with the final closing brace on the last line rather than on a new line. Also unlike LESS, Sass understands Boolean (true or false) values for variables. This enables you to use conditional logic, which you can read about later in this chapter.

sass test.scss test.css --style compressed

In Sass, variables are actually variable rather than constant (which is why in our examples we are naming them in camel case rather than uppercase). You can change the value of a variable as many times as you like:

$color: red;
$color: green;
$color: blue;

#content {
   color: $color;
}

...compiles to:

#content {
  color: blue; }

Scoping of variables also works differently in Sass. Since there is no way to differentiate between creating and modifying a variable, once a variable has been created any attempt to create a variable with the same name in any scope more specific than the initial scope will modify the variable rather than create another. However, scope is still honored in that variables created at a certain scope will not be available at scopes less specific. This is easier to explain with an example:

$color1: red;

#content {
   $color1: green;
   $color2: blue;
   color: $color1;
   background-color: $color2;
}

.callToAction {
   color: $color1;
   //The following line is commented out, since it would cause a compilation error.
   //$color2 has not been created in the scope of this block.

//background: $color2;
}

...results in:

#content {
  color: green;
  background-color: blue; }

.callToAction {
  color: green; }

In this instance, referencing $color2 within .callToAction would result in a compilation error, since $color2 has not been created in that scope (see Figure 9-7).

Figure 9-7. Sass reports clear errors with scoping problems

Note that if the command-line compiler encounters an error, Sass will create an empty file rather than ignoring the command altogether.

Nested selectors in Sass work exactly as in LESS, with one notable difference: Sass uses the & combinator correctly when placed after the current selector. This SCSS:

#content {
   a {
      .callToAction & {
         color: red;
      }
      &.externalLink {

color: blue;
      }
   }
}

... compiles to the following:

.callToAction #content a {
  color: red; }
#content a.externalLink {
  color: blue; }

Sass behaves as we would expect in this instance, whereas LESS would have output #content a .callToAction instead.

Both LESS and Sass will not output rules with no properties. They both happily output identical property and value pairs within the same selector, however:

#content {
   color: red;
   color: red;
}

...compiles to:

#content {
  color: red;
  color: red;
}

As you can see, it reformats the code, but does nothing to minimize unnecessary code. The same applies for the compressed version of the code, both with Sass and LESS.

Something sorely missing from LESS is conditional logic, and looping behavior (described in the next section), which Sass provides more than adequately. If and else clauses are supported. You would use braces to contain the SCSS to evaluate; and @if, @else and @elseif as the conditional commands. A very simple example is as follows:

$christmas: true;

@if $christmas {
   #content {
      color: red;
   }
} @else {
   #content {
      color: black;
   }
}

The resulting CSS is as follows:

#content {
  color: red; }

You can also use the if statements within selectors, just around individual properties. The standard operators are supported:

Here's a simple example:

$lines: 10;

#content {
   @if $lines < 10  {
      height: 20px;
   } @elseif $lines == 10 {
      height: 40px;
   } @elseif $lines > 10 {
      height: 60px;
   }
}

The result is the following:

#content {
  height: 40px; }

Although this can make the SCSS dramatically more complex and difficult to read, it also makes the variables, and Sass as a whole, much more powerful.

Sass supports two methods for looping: @for and @while. For simple iterations from one number to another, @for is the most appropriate. The syntax is simple and involves declaring a variable and defining the beginning and ending points of the loop. The variable can be used as normal during each iteration. Here's an example:

@for $counter from 1 through 3 {
   #product#{$counter} {
         color: green;
   }
}

The resulting CSS is the following:

#product1 {
  color: green; }

#product2 {
  color: green; }

#product3 {
  color: green; }

Sass also supports "from n to n" rather than "from n through n," which simply means that the variable must be less than, instead of equal to, the final digit. In our example, this would have given us two iterations rather than three.

The @while looping is for more complex iterations in which you might like to increment by more than one step for each iteration of the loop, for example. The loop will continue until the condition evaluates to false. Again, the syntax is simple:

$counter: 1;

@while $counter <= 6 {
   #product#{$counter} {
      color: green;
   }
   $counter: $counter + 2;
}

Here's the result:

#product1 {
  color: green; }

#product3 {
  color: green; }

#product5 {
  color: green; }

These kinds of control directives are a very welcome addition to Sass (and are notably missing from LESS).

Sass enables single-line, C-style comments, and behaves exactly like LESS in this respect.

Sass gives you the ability to append a selector to a previous rule—if the selector only has one element—with the @extend keyword. Although the selector to be appended can be of any complexity, the rule it is being applied to must not have any nested selectors. The following code demonstrates this:

.box {
   width:80px;
   height:80px;
}

div#content.main {
   color: red;
}

#content #product {
   color: black;
}

.redBox {
   @extend .box;
   color: red;
}
#content div a.callToAction {
   @extend div#content.main;
   text-decoration: underline;
}
.productBox {
   //The following line would cause an error
   //@extend #content #product;
}

It compiles to the following:

.box, .redBox {
  width: 80px;
  height: 80px; }

div#content.main, #content div a.callToAction {
  color: red; }

#content #product {
  color: black; }

.redBox {
  color: red; }

#content div a.callToAction {

text-decoration: underline; }

You can extend several rules in one declaration. If we had uncommented the marked line, the error would have been as follows:

Syntax error: Can't extend #content #product: can't extend nested selectors
        on line 22 of style.scss
  Use --trace for backtrace.

Although complicated, this technique can be powerful. However, you must be careful if dealing with specificity issues, since Sass rearranges the order of your selectors when extending, and it is easy to place selectors in the file in places earlier than you may have intended.

Mixins follow a slightly different format in Sass. Whereas in LESS, almost any simple selector can be used as a basic mixin, in Sass selectors are created with the @mixin keyword and a unique name, and referenced with the @include keyword, keeping the mixins and rules very separate. In some ways this could be considered less flexible, but it also encourages modular code, makes for code with clearer intent, and avoids some issues you could face otherwise (for example, mixins being output in the eventual CSS when unnecessary or trying to reuse blocks of CSS as mixins with complex selectors). Here's an example:

@mixin border {
   border: solid 1px black;
}

#content {
   @include border;
}

The output follows:

#content {
  border: solid 1px black; }

It is also possible to pass arguments to a mixin in Sass, just as in LESS, but omitting a required argument will cause a clearly identified error. Here's a real-life example:

@mixin borderRadius($radius) {
   -moz-border-radius: $radius;
   -webkit-border-radius: $radius;
   border-radius: $radius;
}

#content {
   @include borderRadius(5px);
}
#product {
   @include borderRadius(15px);
}

.callToAction {
   //The following line would cause an error
   //@include borderRadius;
}

It compiles to the following CSS:

#content {
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
  border-radius: 5px; }

#product {
  -moz-border-radius: 15px;
  -webkit-border-radius: 15px;
  border-radius: 15px; }

If we had uncommented the marked line, the following error would have occurred (in the stdout) since there was no default value set for the $radius parameter:

Syntax error: Mixin borderRadius is missing parameter $radius.
        on line 15 of style.scss, in `borderRadius'
        from line 15 of style.scss
  Use --trace for backtrace.

Like LESS, Sass supports mathematical operations on colors. Sass understands all color formats, including named colors (LESS does not), and works correctly with alpha channels. Sass also exposes many color-specific functions, which are not available in LESS. First, there are color accessors that allow you to expose particular properties of a color variable:

Although hue(), saturation() and lightness() are all available in LESS, the other color accessors are peculiar to Sass.

Using these individual pieces that make up complete colors enables you to build colors based on specific properties of another color, which can be a very advanced technique for building color schemes based on a few primary colors.

We will show a few quick examples with these properties in action. First, we will dissect a named color and use the component parts to build an RGBA color. Here's the SCSS:

$color: red;

$red: red($color);
$green: green($color);
$blue: blue($color);
$alpha: alpha($color);

#content {
   color: rgba($red, $green, $blue, $alpha);
}

Here's the compiled CSS:

#content {
  color: red; }

Interestingly, Sass opts to output this as a named color, which is actually the most efficient thing to do and least open to interpretation. It does this with all colors that can be resolved to named colors, which sometimes is more confusing when reading the outputted CSS, but you would be developing in SCSS so this should not present a problem except when debugging.

In fact, Sass will always convert colors to whatever it deems as the most efficient output. Where possible, it will output them as named colors. Failing that, it will use hex colors. Finally, if there is an alpha channel it will output RGBA. Here's another example:

$color: rgb(1, 2, 3);

#content {

color: $color;
}

$color: rgba(1, 2, 3, 0.5);

#product {
   color: $color;
}

$color: hsla(90deg, 50%, 50%, 0.5);

.callToAction {
   color: $color;
}

Here's the output:

#content {
  color: #010203; }

#product {
  color: rgba(1, 2, 3, 0.5); }

.callToAction {
  color: rgba(128, 191, 64, 0.5); }

This is an interesting decision on the developers' part and important to be aware of. It is a commendable one as it usually makes for the most efficient output.

Sass also provides you with color mutators: functions that modify the value of a color variable. We will list each of them with a brief description:

Although the equivalents of lighten(), darken(), adjust-hue(), saturate(), desaturate(), opacify(), and transparentize() are all available in LESS; the other color mutators are unique to Sass.

With these functions (and the color accessors we previously mentioned), very sophisticated color manipulation and calculation can be achieved. You could generate an entire color scheme or lighten/darken colors for the purposes of creating gradients, and so on. As always, here's a simple example:

$color: blue;

#content {
   background-color: $color;
   color: complement($color);
}

Here's the result:

#content {
  background-color: blue;
  color: yellow; }

Sass supports @import, exactly as LESS does, with two minor differences. Sass will not move @import commands to the top of the file, which while hardly a glaring omission, is a shame since it results in invalid CSS where the @import rule will not be applied. Of course, if your intent is to directly include the CSS as part of your output, you only need to rename the file suffix to .scss (or .less for LESS files). If you use a command like the following:

@import "style.css";

Sass will convert it to the following:

@import url(style.css);

LESS will not do this. It is an unimportant change, since both syntaxes are acceptable according to the CSS 2.1 spec. However, the resulting CSS is larger by three characters. Since @import commands are not prolific in CSS (and we advise against them), we do not feel this is anything to be concerned with.

Sass has many other features, and if you intend to use it as part of your development process, you should read through the extensive and well-written documentation and become well versed with them.

There has been greater uptake with LESS than Sass—perhaps because it is simpler and has looked like CSS from the beginning—so finding staff, application support, and plugins that work well with it is likely to be easier. There is no denying that Sass is more powerful, however, and if you are choosing to use one of these preprocessors you should weigh up the pros and cons of each.

Although less prolific than LESS, methods for compiling Sass at read time with Apache exist, as well as plugins for most major extendable IDEs, and Ruby gems. Whatever your server setup, you will be able to incorporate Sass into it somehow should you wish to do so.

You can read more about Sass at http://sass-lang.com/.

Although there is a feeling of friction against moving toward either of these technologies (LESS or Sass) from many CSS developers because they think it would pose too big an undertaking, this is really an unfounded critique. Since they both support CSS-style syntax, it should be a simple task to rename your original CSS file as .less or .scss and add in new functionality as you see fit. The real criticisms should be the modifications to your build process, the difficulties in debugging, the dependency on a third party and the extra skills required. However, within your organization you may feel these issues are acceptable in return for the many benefits these technologies give you.