What is Sass – Introduction and presentation

Presentation and state of play

Since the appearance of CSS stylesheets, it has always been frustrating not to be able to code like some other languages such as JavaScript or PHP (to name but a few), and therefore, to remain confined to a description language of properties / values.

Although W3C has thought about adopting certain notions such as CSS variables, or, functional notations. The browser companies have been slow in their implementation of these features.

It is somewhere in response to these few proposals that various families of CSS preprocessors, such as, Sass, Less, Stylus, PostCSS, CSSNext, Closure Stylesheets, CSS Preprocessor or Rework have appeared.

The principle of preprocessors

The principle of the preprocessor is simple; it is to write stylesheets through a syntax closer to a real programming language, than a description language.

This can be achieved by using variables, directives that are conditional, loop or control, functions, and sometimes even relying on structures specific to object programming, inheritance, encapsulation or polymorphism.

The goal is to be able to quickly compile all this, whether server-side, or client-side, into standard CSS stylesheets, which will be directly interpretable by browsers, and other devices, or user-agents.

This approach offers more flexibility for development, deployment, maintenance and evolution. Depending on our production environment, we can choose a preprocessor so that it can best respond to the context and to our situation.

There are many preprocessors to choose from, but this series of articles will discuss and illustrate the use of SASS, one of the more popular and powerful pre-processors.

However, whatever preprocessor you choose, it should be portable and adaptable to your situation.

Sass vs Sass

We not only often hear about Sass, but also about Sass or SCSS. What is it? Moreover, is there a difference between these three different names?

So, it’s quite simple, on the one hand when talking about Sass (Syntactically Awesome Stylesheets), we speak of the language itself.

This language is based on two writing syntaxes. The first syntax writes in Sass, which is closer to the one used by Ruby. The second, SCSS (Sassy CSS), is closer to traditional CSS writing.

The first written in Sass

$couleur: #363
.uneclasse
    color: $couleur

or using SCSS

$couleur: #363;
.uneclasse {
  color: $couleur;
}

both will always compile to

.uneclasse {
  color: #363;
}

Although both can be used together in the same project, the two syntaxes can’t coexist within the same file. SCSS files have to be saved with the .scss extension and Sass files with .sass extension. Then, it is only a question of personal choice and context of use … Clearly, if we develop in Ruby On Rails, we will opt for Sass which is easier. If instead we work on the web in traditional HTML / CSS, or if we work frequently on already existing sites, one will then be more easily oriented towards SCSS.

Capabilities of Sass can be extended

The working environment, as well as the tools used, will inevitably differ as we work in PHP applications, for example Symphony, Laravel, Zend, Cake or others, or in a customer-oriented framework, with purely HTML & JavaScript.

In general, and whatever the working environment, we can add a set of add-ins, called extensions, plugins or libraries that will extend the native capabilities of Sass.

Some of the most popular Add-ins include Compass, Bourbon, Sprite factory, Breakpoint, Susy, CSS Sprite, Typesettings, Scut, Buttons, Saffron, Andy…

These additions are very easy to use, generally by installing them under the production environment, and, then importing them into the main document used by Sass.

  @import "compass";
  @import "susy";
  @import "breakpoint";

We will dig deeper, and demonstrate how to install and use them, in the next article.