My experience with CSS preprocessors

Ok, I’ll admit, I tend to be a bit of a purist, especially when it comes to CSS. I never used to understand the need/interest to use preprocessors like SASS or LESS. My reasoning was simple, if you manage to organise your css efficiently, why bother adding all that extra fluff.

I would (and sometimes still do) stuff like this in my single css file :

/**
 * GLOBAL
 * TEXT SELECT
 * CLEARFIX
 * FONT FACES
 * ELEMENTS
 * USEFUL CLASSES
 * HEADER
 * NAVIGATION
 * BREADCRUMB
 * FOOTER
 * HOME
 * PAGES
 * CONNEXION
 * MEDIA QUERIES
 * COOKIES
 */
/**
 * GLOBAL
 * — — — — — — — — — — — — — — — — — — — — — — — — — — -
 */

The idea being to have a table of contents and then to clearly comment each new section to make my file as clear as possible for the next person (or even for myself 6 months down the road).

Thanks to a former colleague, I’m also an advocate of putting my declarations in alphabetical order, I find it much easier to find a certain rule this way, especially when modifying my css.

This is generally how I have done my css for the past couple of years, whether it be a wordpress theme or a site from scratch, I preferred the single file approach (less http requests) and a segmented, commented organisational approach.

Enter Ionic

I had used LESS before, on a multisite Drupal project where “only the colours changed” according to the site. That was pretty much where I thought the interest lay in using preprocessors

However…

I recently had to work on an app using Ionic 2 using SASS. Despite a first couple of days where I still refused to see the interest, basically using the segmented files as a glorified css file but with global variables.

Eventually, after a few criticisms from the back end dev I was working with, I started to get the hang of things and especially seeing why preprocessors have become so popular. I still can’t get over just how powerful the & selector is in SASS.

A few useful snippets

I’ll share with you a few useful snippets I have found (mainly through reading the documentation or from kind people on stackoverflow).

How to organise your files

$font-path: “../fonts”;

// KEY FILES
@import “variables”;
@import “normalize”;
@import “lato”;
// GENERAL STYLES
* {
 box-sizing: border-box;
}
html {
 font-size: 16px;
 height: 100%;
 overflow-x: hidden;
}
body {
 background: $light-grey;
 color: $text;
 font-family: ‘Lato’, sans-serif;
 font-size: 100%;
 line-height: 1.3;
 overflow-x: hidden;
 position: relative;
 width: 100%;
 /**/
 -webkit-font-smoothing: subpixel-antialiased;
 -moz-osx-font-smoothing: grayscale;
}
// COMPONENTS
@import “elements”;
@import “components/panel”;
@import “components/box”;
@import “components/chart”;
@import “components/paginator”;
@import “components/datatables”;
@import “layout”;
@import “sidebar”;
@import “login”;
@import “dashboard”;
@import “users”;

I have one file (theme.scss) where I set very basic rules and import the rest of my files. You will notice that my file starts with key imports before doing anything else. This allows me to use my variables and fonts anywhere without generating any errors.
At the bottom of the file I do the rest of my imports.
Just so you know, I have a gulp task that compiles my sass into one css file which is autoprefixed then minified.

Divide & Conquer

// COMPONENTS
@import “elements”;
@import “components/panel”;
@import “components/box”;
@import “components/chart”;
@import “components/paginator”;
@import “components/datatables”;
@import “layout”;
@import “sidebar”;
@import “login”;
@import “dashboard”;
@import “users”;

Where once I had my table of contents and a single file with (lots of) comments, I know have well segmented files that each have specific tasks and are as short as possible (to help comprehension). My components folder is for elements that reusable and have their general styles defined at this location. If a certain page requires a some changes for the component, I will put these changes in the page specific scss file.

The advantage of this approach is that everything is clearly labelled and you don’t have to trawl through a file with more than 5000 lines. I know of certain webdesigners who do all their LESS in one single file, with no comments and no particular order to their declarations. Good luck if you have to modify they styles.

The &

.menu-toggle {
 background: none;
 border: 0;
 display: block;
 height: 30px;
 outline: none;
 padding: 0;
 position: relative;
 width: 30px;
     span {
        background: #fff;
        display: block;
        height: 3px;
        margin: 0 auto;
        position: relative;
        transform: translateY(0);
        transition: $transition;
        width: 30px;
        &:before,
        &:after {
            @extend span;
            content: ‘’;
            margin: 0;
            position: absolute;
            top: -9px;
        }
        &:after {
            top: 9px;
        }
        .js-nav & {
            background: transparent; 
            &:before {
                background: #fff;
                transform: rotate(45deg);
                top: 0;
            }
            &:after {
                background: #fff;
                transform: rotate(-45deg);
                top: 0;
            }
        }
    }
}

In this block, I’m dealing with a button that changes when the body has the class .js-nav added to it. If you notice the line

.js-nav & {

This basically means that what follows will happen when I have .js-nav .menu-toggle. Putting & at the end of the selector means it will be placed in front of the selector that opened the stack. Just one reason why you should try and limit the number of indentations when you write SASS/LESS.

Font sizes in REM

I put all my font sizes in rem, but it can be extremely annoying to calculate the size, and even more so when you have to modify someone else’s code. That’s why when I wrote just css, I declared the font size twice, once in px and then in rem, basically for more clarity.

One of the great advantages of preprocessors is the ability to calculate equations. Hence, for my font size declarations I can now use

font-size: (24 / 16) + 0rem;

24px being the font size in the .psd. I also systematically define the document’s font size at 16px just to be sure.

In conclusion

I was wrong (kind of). I now try to implement sass as often as I can in my workflow. Coupled with a few well placed gulp tasks, you can rediscover the pleasure of writing css.

I’m still not entirely convinced on how I divided up my files and find it a challenge to limit myself to a maximum (3/4) of indentations to keep my final css file as clean as possible, but it’s a great learning curve to be on and definitely one I could recommend.