Sass: Variables and modular scss stylesheets

The larger a web project, the more cumbersome the stylesheet. This is a generalisation of course, but has a basis in reality. For larger projects, or complex systems, css maintenance is an issue.

Many developers mitigate this by splitting it into smaller related stylesheets. A functional approach, but not without the additional cost of extra http requests to load them, and making sure they load in a particular order if there are any potential conflicts.

CSS Pre-processors

This is where CSS pre-processors enter. Pre-processors extend CSS with variables, operators, interpolations, functions, mixins and many more other usable assets.

Pre-processors, with their advanced programmatic features enable, and reinforce, a much more structured approach to CSS, and aid in producing reusable, maintainable and extensible CSS. By using a pre-processor, it is possible increase productivity, while decreasing the amount of code required.

I’ve dabbled with Less in the past, but have moved to Sass, primarily as Bootstrap 4 will move to this, and additionally it appears that Sass is quickly becoming the defacto standard, over Less, Stylus and others.

Variables in Sass

Variables have been a much requested feature for CSS. They make it easy to update code and reference values by allowing you to assign an identifier to a value – the ability to to define a base state e.g. for color and use it multiple times in the CSS file, instead of repeating the same hex or named color in a property. The same goes for properties such as ‘width’, ‘font-size’, ‘background’, ‘border’ etc.

Variables start with $ sign – which is a nice c-like usage – and values are assigned with a colon. For example:

// set base color
$color: #444;

div {
    color: $color;
}

Modular Sass structure

One aspect of using Sass that crops up time and again is modular Sass structure. A feature of Sass is the ability to structure disparate theme concerns into separate scss files for compilation at runtime. The .scss extension denotes it as a Sass file. During compilation this is converted to a .css file. If however it is given an underscore prefix e.g. _buttons.scss, then the .css file is not created. This is advantageous if another major feature of Sass is being used: importing.

Rather than one large file, separation into smaller files and folders, grouping the similar code chunks together, is helpful for increasing maintainability and control. With multiple import statements a framework structure can be created. This enables a team of designers & developers to work on different aspects of the theme at the same time while keeping the overall project goal in mind.

// main,scss imports
@import "mixins/mixin.scss";
@import "reset.css";
...

But, what if certain theme styling is restricted to only particular parts of the theme, such as buttons? If the overall look and feel has already been decided – which it invariably is at this point – then changes in theme will tend to be at the scope of the module concerned, e.g buttons, with a slightly different background or hover effect, or images with a different border.

It makes sense for theme variables – variables, mixins, maps etc, to also be modular, and controlled by their own scss file. That is not to say that some theme variables, which are used throughout the site shouldn’t be restricted to the global scope, i.e. the main scss file into which modules are imported.

There are various options to structure this:

Simple: For smaller projects, such as a basic website, one option is to create a core file, which contains the majority of reusable variables & mixins etc, and import this to the top of the main scss file. The main css could then be imported as an associated scss file. A modular approach to parts of the style that can be encapsulated into their own groups could then be used, as partials e.g. _buttons.scss, _widgets.scss, _header.scss, _footer.scss. Into these could be placed specific variables/mixins which are particular to their style.

// CSS Reset
@import "reset.scss";

// Core
@import "variables.scss";
@import "mixins.scss";

// Grid system and page structure
@import "grid.scss";

// Styled patterns and elements
@import "buttons.scss";
@import "forms.scss";
@import "tables.scss";

Framework: For a larger project, where potentially there are multiple developers/designers, or simply the scope is such that the code base needs to be refactored, then a framework like approach is useful. In such cases the compilation is driven by a primary file, e.g. app.scss. Into this is added a structured set of imports for variable, mixins, partials etc. Both variables/mixins and partials/components are structured around their particular requirements. and within their own folders. For example:

// CSS Reset
@import "reset.scss";

// Variables & Mixins
@import "mixins/core.scss",
        "mixins/grid.scss",
        "mixins/header.scss",
        "mixins/footer.scss",
        "mixins/buttons.scss",
        "mixins/forms.scss",
        "mixins/tables.scss";

// Page structure & Components
@import "partials/grid.scss",
        "partials/header.scss",
        "partials/footer.scss",
        "partials/buttons.scss",
        "partials/forms.scss",
        "partials/tables.scss";
...

Wrapping It Up

Hopefully a useful basic insight into Sass and its modular potential. I’m sure there are plenty of ways of doing this.