Entrance to Sass

CSS simplicity is one of the most desirable and distinguishing features of CSS, as CSS style sheets are nothing but long lists of commands, each of which specifies the selector and some of the styles to be applied to it. However, as our websites and applications are getting bigger and bigger and increasing their complexity with that, and they are targeting different devices and screen sizes, the simplicity that characterizes CSS quickly becomes a burden on the shoulders of programmers by virtue that the matter is no longer related to only some basic properties.

While some have suggested solutions to CSS problems by adding variables and constants to them, for example, browsers refrain from using and supporting them. Even if any of the browsers support a new, more advanced version of CSS, it will take years to generalize the matter to all browsers, making it an incorrect idea to rely on it.

Fortunately, a few years ago, developers Hampton Catlin and Nathan Weizenbaum suggested a better way to deal with complex pattern sheets. Since browsers are not ready to adopt a new version of CSS, the two developers found that they can design new syntax for style sheets that make the task of writing and maintaining those sheets easier, as it suffices to use a preprocessor to translate the new syntax into the old syntax used in the CSS sheets we know.

The new composition has been named Sass which is short for syntactically awesome style sheets. The early versions of Sass were very different from classic CSS, for example there were no curly braces, and the indentations had to be indented in a specific way and with a specified number of spaces to avoid errors when compiling the file. The matter did not prevent programmers who are accustomed to learning new programming languages ​​and enjoying this from dealing with this language and did not find a problem with the new structures that Sass brought, but the matter was different with the designers who saw that the linguistic structure of Sass was very different from the CSS that They wrote it so they didn't want to use it. The other problem is that the difference in syntax with classic CSS makes the task of leveraging Sass in current projects impossible without spending a lot of time translating your existing CSS files into Sass.

To ward off these problems, developers in Sass 3.0 added a new linguistic syntax that is closer to CSS, which they called SCSS or Sassy CSS. SCSS is often described as a Strict Superset or a sublanguage derived from CSS which means that any file deemed properly structured in CSS will be structured in SCSS as well. In other words, you can use your existing CSS files with the Sass Preprocessor without any problems, which will allow you to learn and use some of Sass's features without having to learn all the features to use it.

Contrary to normal CSS, Sass / SCSS can be considered a scripting language in every sense of the word, as it supports many properties of programming languages ​​such as: expressions, functions, variables, conditional logic, and loops. Of course, you do not need to use all of these features at once, but it is restricted to you when you need it, and it will make the task of writing complex pattern sheets - which usually contain duplicate codes - very easy.

In this article, we will review a set of Sass / SCSS rules to give you a clear idea of ​​what you can do using this new language, and we will conclude with a collection of links and books if you want to go far with it.

To keep it as simple as possible, in most of the examples we will review here, we will focus on SCSS code only, not the CSS code that results from it after compiling it. Of course, the best way to learn Sass is to try it yourself, write some code, and notice the CSS files that result from it. All the examples shown here as well as the CSS files that they generate can be found on this repository on Github.

The beginning

Sass is written in Ruby, and is distributed via its RubyGems package manager. Those who use Ruby or who do not have difficulty in dealing with the command line will be able to easily install Sass by following the instructions on the Sass site, and those who have difficulty in this or have never dealt with Ruby can rely on the Scout application on Windows and Mac which comes Equipped with Probi and Sass (if you are on Linux, you are supposed to be comfortable with the command line and thus ...).

Whether you install Sass via the command line or via the Scout application, the principle of work remains the same. Your SCSS files are monitored and every time they are updated and saved it is translated into a classic CSS file. We name the Input Folder the folder that contains the Sass files, and the resulting CSS files are saved in a folder called the Output Folder. One of these folders can be inside the other, but it is common for it to be the input folder, which we can call scss, inside the style sheets folder for your project, which we call css as follows:

my_project/
  index.html
  css/
    main_style.css
    scss/
      main_style.scss 
      _mixins.scss
      _colors.scss

In the previous example, files whose names begin with _ within the scss folder are called partials description and so described because they are partial style sheets that are imported into the main SCSS files.

Use partial files to organize your code

CSS provides the @import directive to import additional css files, and developers often use this directive to split large projects into smaller files to make it easier to maintain. For example, the main file main_style.css can only contain a set of @import directives as follows:

@import url('/shared/global.css');
@import url('/pages/home.css');
@import url('/pages/blog.css');

The preceding code results in only one CSS file. Sass can do minification of the resulting CSS file and eliminate all extra spaces to improve site performance and reduce its load time.

One thing to keep in mind is that partial files are SCSS-specific files that are not intended to be used as classic CSS files, and import them using the @import directive should be taken into account. 

@import 'shared/global';
@import 'pages/home';
@import 'pages/blog';

Partial file names also start with the character "_", since in the previous example pages / home imports the pages / _home.scss file. The _ character allows Sass to know that the file is a partial file and thus avoids translating it into a standalone CSS file.

Don't repeat what you are doing

With our style sheets becoming more organized, we must now get rid of duplication in their content.

One of the most important features of Sass is its Nested rules feature. In classic CSS files, different rules come in after another, and each rule's delimiter must include all of its elements:

body.home .media-unit {
  border: 1px solid #ccc;
  background-color: #fff;
}
body.home  .media-unit .right {
  border-left: 1px solid #ccc;
}
body.home .media-unit .right h1 {
  font-size: 24px;
}

Moreover, this code contains a lot of redundancy, it does not help us to understand the relationship between the elements to which we are adding display styles. But thanks to the built-in rules, we can write SCSS code that not only avoids redundancy, but also makes knowing the relationship between elements clearer and easier to understand:

body.home {
  .media-unit {
    border: 1px solid #ccc;
    background-color: #fff;
    .right {
      border-left: 1px solid #ccc;
      h1 {
        font-size: 24px;
      }
    }
  }
}

After translating this code, we will get the same code as the previous one. Unfortunately, the small size of SCSS code does not necessarily result in CSS code that is also small or fast to load, but using the built-in rules will keep the code cleaner, more logical and more organized, features that will make it easier to manage and maintain this code over time.

Built-in rules also allow media queries to be embedded within other rules, making it easy to see which style is executed on any of your page elements:

.container {
  width: 940px;  // If the device is narrower than 940px, switch to 
  // a fluid layout
  @media screen and (max-width:940px) {
    width: auto;
  }
}

When translating this code, Sass converts it into classic CSS code by copying the .container selector into media query as follows:

.container {
  width: 940px;
}@media screen and (max-width:940px) {
  .container {
    width: auto;
  }
}

Variables

Sass variables are very useful for two reasons: the first and the most important is to facilitate the task of modifying the code and avoid repetition, and the second is to enable the developer to give special names to some properties, especially colors, which increases the readability of the code and is easy to understand.

On Typekit, for example, we find that many of the elements use the color # 99CC00, or what the site's developers call Typekit green for short. Since this color is used in all parts of the site, starting with the buttons and ending with the headings, in the event that we want to change this green color to another color, we must replace this value with another value wherever it appears on the CSS file. But in the event that Sass variables are used instead of the aforementioned hexadecimal value, it is sufficient to change the value of the variable concerned with this color (which can be defined at the beginning of the file or even in partial files) so that it is changed in all page elements simultaneously and automatically. Variables can also be used to give values ​​to other variables making it easier to keep your patterns more organized:

$typekit-green: "#99cc00";
$typekit-link-color: $typekit-green;a {
  color: $typekit-link-color;
}

You can also give these variables almost any value you wish, and just as these variables served us with colors, they will also benefit us with fonts:

$sans-serif-font: 'ff-dagny-web-pro', 'Helvetica Neue', Arial,  
Helvetica, 'Liberation Sans', sans-serif;
$serif-font: 'ff-tisa-web-pro', Georgia, Times, serif;.banner h1 {
  font-family: $sans-serif-font;
}

MIXINS

Mixins are a set of rules or properties that you can include or 'combine' with other rules. We define these groups using the @mixin statement and include them in other rules with @include.

In the following example, we ask Sass to implement all of the properties in the highlighted-bold-text attribute set to the span elements inside result-with-highlights:

$highlight-color: #ffa;@mixin highlighted-bold-text {
  font-weight: bold;
  background-color: $highlight-color;
}.result-with-highlights {
  span {
    @include highlighted-bold-text;
  }
}

It suffices to define the mixin once so that you can use it wherever you want in the same file. In the following example, all the properties of the previously defined mixin are added to the class named highlighted:

.highlighted {
  @include highlighted-bold-text;
}

This is especially useful when adding CSS3 features to some elements with the desire to ensure that these elements appear the same on all browsers by using prefixes for each browser in addition to providing a graceful rollback for browsers that do not support these features. Working with different prefixes in classic CSS files is usually a hassle given their length and the need to copy and paste them every time. But with mixins it is possible to do this much faster, without making mistakes, and without having to write a lot of code.

In the following example, we're adding a 4px rounded edge to an element by using the Webkit, Firefox, and IE prefixes with the addition of the CSS3 border-radius property. We also specify the value of the rotation in a variable in order to facilitate the task of adjusting it later:

@mixin rounded-corners {
  $rounded-corner-radius: 4px;
  -webkit-border-radius: $rounded-corner-radius;
  -moz-border-radius: $rounded-corner-radius;
  -ms-border-radius: $rounded-corner-radius;
  border-radius: $rounded-corner-radius;
}.button {
  @include rounded-corners;
}

Mixins can contain complete built-in grammar, not just attributes. The following example shows how to write a clearfix CSS using a Sass mixin:

@mixin clearfix {
 // For modern browsers
  &:before,
  &:after {
    content:"";
    display:table;
  }  &:after {
    clear:both;
  }  // For IE 6/7 (trigger hasLayout)
  & {
    zoom:1;
  }
}.group {
  @include clearfix;
}

& In Sass stands for "Current Item", since when translating the file it is replaced by the current Selector. In the previous example it will be replaced with .group

Smarter Pattern Sheets

Using mixins to implement specific patterns on some elements is very useful, but the most beneficial and most wonderful is the ability to use arguments just as it is with different programming languages ​​such as JavaScript and PHP, and it can also be used with other more advanced features such as expressions and functions in order to go further than Just organize style sheets and implement more complex patterns.

One of the most popular uses of Sass is Grid Layout systems. There are many ready-made 960px systems, but most of them require adding non-semantic class names to your code, in addition to your need to load the entire system into your project before using it even if you do not want to use only a small part of it.

In our last example in this article we will create a 12-module Grid Layout using Sass. Instead of using a special name for each unit, we will give mixin the task of determining the most appropriate width and margins for each element to convert into a unit in the grid system that we are preparing.

First, we need to define the width and margins of each column:

$column-width: 60px;    // 12 columns = 720px
$gutter-width: 20px;    // 11 gutters =

And then we ask Sass to calculate the width of each unit on our behalf, as the width of each unit is equal to the sum of the widths of the columns it covers in addition to the margins that intersect it, and thus it can be calculated as follows:

width: ($column-width * $span) + ($gutter-width * ($span – 1));

Therefore, we will write mixin that accepts one variable (represented by the number of columns span). Each unit will be aligned to the left, and a margin of 20px will be added between units, and a margin will be added to the right of each unit with the same value:

@mixin grid-unit($span) {
  float: left;
  margin-right: $gutter-width;
  width: ($column-width * $span) + ($gutter-width * ($span - 1));
}

Despite the simplicity of the previous code, it is very powerful, as we can, for example, implement a base pattern consisting of a column containing two thirds of the area and another column containing the remaining third as follows:

.container {
  @include clearfix;
  @include grid-unit(12);
  float: none;
  margin: 0 auto;
}.main-content {
  @include grid-unit(8);
}.sidebar {
  @include grid-unit(4);
  margin-right: 0;
}

And that's just a small part of what you can do with Sass.

Sass's support for algorithms makes the job of working with adaptive fluid-width layouts easier. In the following example we use Ethan Marcotte's "recipe" to convert the previous design into a custom design. Since Sass does not convert between units unless explicitly requested, we use the percentage () function to do this:

.container {
// result = target / context
  width: percentage(940px / 960px);  .main-content {
    // This is nested inside of .container, so its context is 940px
    width: percentage(620px / 940px);
  }  .sidebar {
    width: percentage(300px / 940px);
  }
}

Sass also has functions to control colors such as brightness, darkness, transparency, etc. as follows:

$base-link-color: #00f;
a {
  color: $base-link-color;
}
a:visited {
  // This reduces the lightness of the color (in HSL terms) 
  // by 50%, leaving hue and saturation alone
  color: darken($base-link-color, 20%);
}figcaption {
  // Generates an rgba() color value with 50% opacity
  background-color: transparentize(#fff, 50%);
}

If these functions are not enough in your opinion, you can add other functions, share them and reuse them between your various projects via partial files. Check out the full list of Sass functions to get an idea of ​​what they can do.

Are there more?

The official Sass website contains a lot of important and useful information for those interested in learning Sass, and it contains a comprehensive guide for all the features and advantages of SCSS.

If you prefer reading books, you may want to read “Pragmatic Guide to Sass” co-authored by Sass developer Hampton Catlin.

If you want to go further, you might want to take a look at the Compass library, which contains a wide range of SCSS style functions that support both Eric Meyer's CSS reset sheet, Blueprint grid system, as well as many CSS3 features and effects. , Which its developer describes as "jQuery for stylesheets."

If you use the scout application, you will find Compass directly available in it, and you can install it by following the instructions provided on the library website.

Translated -and acted- of David Demaree's Getting Started with Sass article