Sass Variable Architecture

Using Sass is helpful when authoring and maintaining CSS. One of its many advantages is being able to define variables that can be reused again and again. Creating a scalable and easy to use variable structure has been something I’ve been working on and researching for quite some time now. Below are a few of my findings.

1. Use Auto-Complete Friendly Terms

Many IDE including Sublime Text offer an autocomplete when you start typing a word or function. Autocomplete allows you to work more efficiently, by not having to remember each of your variable variations. When you’re working in the CSS, you probably know from working within the PSD that the item you’re trying to style is supposed to be blue. In the first example, this works great with autocomplete. You start typing “$blu” and you’ll get all the results from the first list. This isn’t the case for the second least and can become confusing if you use the same name convention for the other colors in your scheme ($lightYellow, $lightRed).

Do – Start with the Color

$blue: ###;
$blueLight: ###;
$blueDark: ###;

Don’t – Start with the Variant

$blue: ###;
$lightBlue: ###;
$darkBlue: ###;

2. Utilize User Friendly Terms

As the author of the CSS, you might have been provided a style guide with brand colors for the project. It’s important to name these colors as they relate to the interface rather than an arbitrary hierarchy. I’ve found that there are typically 3 main colors in designs. A primary color for primary actions like an “add to cart” or some other main call to action, a secondary color for secondary action, and an alt color for unique cases where the other two don’t apply. Then there tends to be variants on those three colors. By creating this relationship and standardizing a naming convention, you create a direct relationship with the interface and your variables. This will also help future developers to be able to easily understand and relate which color goes with which variable.

Do – Abstract Color Names

$primary: $blue;
$primaryLight: $blueLight;
$primaryDark: $blueDark;
$secondary: $yellow;
$secondaryLight: $yellowLight;
$secondaryDark: $yellowDark;

Don’t – Abstract Ambiguous Color Names

$brand-1: $blue;
$brand-2: $yellow;
$brand-3: $blueLight;
$brand-4: $blueDark;
$brand-5: $yellowLight;

3. Use a Calc Function and a Font Size Mixin

The REM unit is still not well supported and there may be other situations where you want to change the root body element font size. If you’re using EM based CSS, changing that value can have a big impact on your layout and design. By setting a $base-font-size variable and using it as the basis for all your root EM base calculations, you can make sure your CSS remains fluid. The $base-font-size variable also comes in handy to reset the font-size on inline-block elements whose parents’ font-size is set to 0 in order to overcome the inline-block white-space shortcoming.

Do – Use Calc and Font Size Mixins

.selector {
    margin-bottom: calc-target(10,14);
    line-height: calc-target(20,14);
    @include font-size(14);
}
$base-font-size: 16 !default;

// ==========================================================================
// calc target
// ==========================================================================

@function calc-target($target, $context: $base-font-size, $unit: 1em) {
    @return $target / $context * $unit;
}

// ==========================================================================
// @mixin font-size
// ==========================================================================

@mixin font-size($targetSize, $base: $base-font-size) {
    font-size: $targetSize / $base * 1em;
}

4. Create a Default Architecture with Overrides

From project to project, some things change, but many stay the same. Whether it’s the path to your image directory, the color of error text, or the different samples of grey you use, keep these things constant for every project and refine them over time with your base CSS architecture. Keep these defaults in one file, and in a separate file, create project specific overrides. Now in your compilable Sass file, call the default variable file first, and the project overrides afterward. Much like using plugins in JS, this keeps your project separate from the core architecture and is easier to update/upgrade to newer versions.

Do – Use !default Values

//system
$imagePath: '/resources/images' !default;
$fontPath: '/resources/fonts' !default;

//greys
$greyWhite:         #fff !default;
$greyLightest:      #fafafa !default;
$greyLighter:       #f2f2f2 !default;
$greyLight:         #ddd !default;
$grey:              #ccc !default;
$greyDark:          #666 !default;
$greyDarker:        #444 !default;
$greyBlack:         #222 !default;

// system colors
$ui-yellow:         #c09853 !default;
$ui-yellowLight:    #fcf8e3 !default;
$ui-red:            #b94a48 !default;
$ui-redLight:       #f2dede !default;
$ui-green:          #468847 !default;
$ui-greenLight:     #dff0d8 !default;
$ui-blue:           #0484cb !default;
$ui-blueLight:      #d9edf7 !default;

posted in: Front End Development
tagged: , ,

Comments are closed