Upgrading from CSS to SASS

Pretty much all of my projects so far in my exploration into software development have involved some degree of CSS or another. In terms of putting together the front end side of the project, this included the spacing on the page, responsive design to the size of a device and its browser, choosing colours, fonts, image and video sizes, animations and much more.

The finalised, pristine and professional looking sheen has been occasionally sacrificed for the cause of completing a project (especially during a month of completing a new project every single day), or in a focus on functionality over user experience within a particular time period or learning objective.

However spending extra time with CSS is a great way to add originality or personality to a project, is easy to experiment with, and small changes can make massive improvements in user experience. A non-developer but simple contemporary technology user will be spending their precious time away from less user-friendly sites if they can.

A large percentage of professional sites built by experienced and accomplished developers use CSS pre-processors, however, and this is not something I have used in projects of mine before. I decided to get started with more advanced CSS design and upskill in this area by learning some Sass (Syntactically Awesome Style Sheets — to go by its longer name).

The newest syntax for Sass — Sassy CSS, or SCSS for short, enables any CSS file as a valid SCSS file, and SCSS syntax is considered more intuitive for those already familiar with CSS. This includes the use of semi-colons at the end of a line, and the use of curly braces. The old syntax of Sass avoids both of these, and whilst still valid, makes converting CSS files or switching to Sass from CSS more cumbersome than using SCSS syntax.

Sass files will have the extension .scss or .sass depending on which syntax is being used, rather than CSS.

Sass can be installed on the command line using Node with the following command:

npm install -g sass

And the documentation for reference can be found here: https://sass-lang.com/documentation

What are some of the features of SCSS?

Variables

Sass/SCSS allows for the introduction of variables, which can be referred to for different elements (by class, ID, tag name etc.), allowing for these variable’s values to then just be changed once rather than requiring updating for every single use case, saving time and avoiding unnecessary errors or oversight.

These can be for colours (see examples below):

$colour-primary: #52fde8;
$colour-primary-light: #a4fbed;
$colour-primary-dark: #00ffe2;
$colour-primary-extra-dark: #008080;
$colour-grey-dark: #777;
$colour-white: #fff;
$colour-black: #000;

Which then can be referenced later in the code (or in a separate file if linked):

&--white {
    background-color: $colour-white;
    color: $colour-primary-extra-dark;
}

Or width, or font size or anything really:

$grid-width: 114rem;
$vertical-margin: 8rem;
$horizontal-margin: 6rem;

And:

.row {
  max-width: $grid-width;
  background-color: #eee;
  margin: 0 auto;
&:not(:last-child) {
    margin-bottom: $vertical-margin;
  }

Mixins

Mixins are useful for larger collections of styles that you want to define and reuse.

They are declared using @mixin and you can name them pretty much whatever you want (with some sensible exceptions, and obviously it will be easier to read your code if you name it something relevant!):

@mixin clearfix {
  &::after {
    content: "";
    display: table;
    clear: both;
  }
}

You can apply a mixin by referencing it in the correct file within the block for the class/ID/tag etc. you want to apply its styles to:

.row {
  max-width: $grid-width;
  background-color: #eee;
  margin: 0 auto;
@include clearfix;
}

Nested rules

Nesting rules is an alternative syntax to standard CSS which can allow for DRY code and save time and lines of code. There are plusses and minuses to using them, and it can be much more beneficial to use them in certain cases than in others, but it offers another option.

Standard CSS syntax would

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

nav li { 
    display: inline-block; 
}

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

Whilst an SCSS file could look like this, with the unordered list, list items, and links of the navigation bar nested within the nav code.

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

  li { 
    display: inline-block; 
  }

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

Functions

Sass has built in functions (and the use of the mathematical operators), but allows for custom functions to be built and reused in your code, e.g.:

@function divide($first-number, $second-number) {
  return ($first-number / $second-number)
}

Which could then be used for calculating the number of rem, em, pixels, a percentage etc., such as in the example below:

.column {
   width: divide(($table-width / 4) + $column-margin);
}

All of these features are useful, and I look forward to employing for future projects, as well as exploring returning to previous projects using standard CSS and taking it to the next level by adding a little sassiness. It is all part of the process of becoming as accomplished and skilled a developer — in this case as a Front End Developer — as I can possibly be.

The Sass documentation itself describes Sass as CSS with superpowers. Well I am no superhero but I’ll happily take some of the magic if it’ll make me a better developer.