Everything about Sass - what it gives us and why to choose it

Wait a minute… what exactly are CSS preprocessors?

CSS preprocessors are actually strengthened CSS. The main idea behind it was to enrich CSS with some mechanisms known from traditional programming languages that are not available in CSS3. The list of functions enabled thanks to preprocessors is really long, but it is up to us what features we are going to use.

To keep it short: the preprocessor is responsible for recompiling the existing code into the format compliant to the CSS standard. After the recompilation we receive a native code that is adjusted to every web browser.

Three key players on the market: Sass, Less and Stylus

Statistics differ from one another, so it is hard to point the most popular CSS preprocessor out, but the one thing in these reports is constant: this market is dominated by three players – Sass, Less and Stylus.

• Sass (Syntactically Awesome Style Sheets) is by far the oldest from these three. It was introduced in 2006. It can be safely said that Sass was the pioneer of CSS preprocessing. At the time of writing this article Sass 3.4.19 was the newest version.

• Less (Leaner CSS) was created as the answer for Sass. The first version was introduced in 2009 and it caused, among others, the implementation of a new scss syntax – the later part of the article covers it. The current version is identified as 1.7.3

• Stylus is the youngest of these three, it was created in 2011. The newest version - 0.52.4 – was published on 4 September.

Merix stand up on Sass

After long talks and exchanging our experience about these preprocessors we decided to use Sass in our daily work.

These arguments for Sass convinced us to choose it over others:

• the possibility of using advanced frameworks that use Sass, such as Compass or Bourbon

• huge Sass developers community

• quicker code compilation than in other preprocessors

• even the best switch to Sass ;)

Syntax (sass vs scss)

Sass allows to code in two syntaxes – sass or scss. They differ in code formatting.

The sass syntax uses indentation instead of braces, rules are separated by the newline sign instead of a semicolon used in classic CSS code. That approach may resemble the code created in YAML or Haml.

The scss syntax, despite being younger, comes back to the classic way of code formatting in CSS. Braces are used in order to define blocks, semicolons separate rules from themselves. The biggest advantage of using scss is its compatibility with the standard CSS code.
In the further sections of the article we are going to use the code compliant with the CSS syntax.

style.sass

h1
color: #000000
text-align: center
text-transform: uppercase



style.scss

h1 {
color: #0000;
text-align: center;
text-transform: uppercase;
}

Sass together with Gulp

In one of our previous articles Mateusz described Gulp.js – the system for work automation. One of the tasks we use on daily basis compiles our Sass code into the native CSS one due to the use of plugin-gulp-sass which can be installed via npm (node package manager). Thanks to that the installation is limited to a single task. The configuration takes a bit longer, but it is at least greatly documented on the official website of the plugin. Under this link you may check it for more information.

What Sass has to offer?

Variable

Sass allows to declare variables accessible throughout the whole style sheet. The variable may have a numeric value (including units of measure, string (with or without quotations), color or Boolean value. Variables in Sass are preceded by "$" sign, the colon ": " separates the name from the declaration.

style.scss

$font-color: #000000;
$font-family: Arial, sans-serif;
$font-size: 48px;

body {
color: $font-color;
font-family: $font-family;
font-size: $font-size;
}

Multilevel nesting

CSS supports logical nesting, however it is not reflected visually in code. The implementation of the advanced nesting greatly improves readability of the code and reduces its volume.

style.scss

nav {
ul {
margin: 0;
padding: 0;
list-style: none;
}
li {
display: inline-block;
}
a {
display: block;
padding: 5px 10px;
text-decoration: none;
}
}

After the recompilation:

style.css

nav ul {
margin: 0;
padding: 0;
list-style: none;
}

nav li {
display: inline-block;
}

nav a {
display: block;
padding: 5px 10px;
text-decoration: none;
}

Mixins

One of the biggest flaws of the default style sheets is the necessity of copying the code into every place it appears. Mixins solve that problem. Additionally mixins work similarly to functions. The proper Sass code has to be the result of inserting a mixin. Just like functions, mixins can take parameters.

@mixin declares this class and we refer to it by using @include.

style.scss

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

.box1 {
@include border-radius(10px);
}

.box2 {
@include border-radius(10px);
}

After the recompilation:

style.css

.box1 {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
border-radius: 10px;
}

.box2 {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
border-radius: 10px;
}

Expanding/inheriting

Sass allows to inherit styles from one selector to another. It is yet another functionality that prevents from unwanted repeating of the code (Don’t Repeat Yourself! rule).

style.scss

.message {
border: 1px solid #ccc;
padding: 10px;
color: #333;
}

.success {
@extend .message;
border-color: green;
}

.error {
@extend .message;
border-color: red;
}

.warning {
@extend .message;
border-color: yellow;
}

Will be recompiled as:

style.css

.message, .success, .error, .warning {
border: 1px solid #cccccc;
padding: 10px;
color: #333;
}

.success {
border-color: green;
}

.error {
border-color: red;
}

.warning {
border-color: yellow;
}

Importing

Dividing stylesheets into smaller pieces improves clarity of the code and simplifies expanding it in the future. The native CSS is capable of importing files, however this solution has a one disadvantage – every imported file generates a new HTTP request.

Sass has a different approach to importing files. Every time we import a file, Sass downloads its content, inserts it into the target file and saves it as a single output file. Thanks to such an approach the browser generates only one HTTP request.

reset.scss

html,
body,
ul,
ol {
margin: 0;
padding: 0;
}


base.scss

@import 'reset';

body {
font: 100% Helvetica, sans-serif;
background-color: #efefef;
}

Will be recompiled as:

style.css

html, body, ul, ol {
margin: 0;
padding: 0;
}

body {
font: 100% Helvetica, sans-serif;
background-color: #efefef;
}

Conclusion - why to choose Sass?

CSS preprocessors revolutionized frontend development. While some designers cannot imagine working without them, others have skeptical approach towards them. I hope that by bringing closer the topic of preprocessors I encouraged you to give them a chance. Who knows, maybe they become an integral part of your everyday workflow.