Skip to Content

When to Use CSS Preprocessors (Spoiler Alert: Always)

Part of my job here at ITX is to ensure that we are using the latest development techniques, which allow us to build the highest quality digital products, while remaining efficient – both during the initial development phase, as well as during the maintenance lifecycle of one of our products. I am interested in seeing what tools are available to help us with this goal.

Several years ago, I was introduced to the concept of CSS Preprocessors, which to me felt like a revelation. They were what CSS should have represented by design. Since then, I continue to come across people who have yet to be introduced to CSS Preprocessors, so it didn’t feel right to not share that revelation. So, let’s start with the basics.

What is a CSS Preprocessor?
Naturally, we should define what I am talking about. When I say, CSS Preprocessor, I mean a tool that extends CSS to new logical structures, whereby as a developer, you can define variables, mixins (similar to functions) and maintain global attributes in a way that makes sense. Tools like, SASS, LESS and Stylus are a few examples of CSS Preprocessors. If you haven’t already, you should check them out.

So, Why Use a CSS Preprocessor?
If you are a developer, remember the first time that you used jQuery? It felt like a revelation. It ultimately took tedious JavaScript code and isolated it into discrete APIs – making your life easier. A CSS Preprocessor ultimately does the same thing for your style management within your application.

Variables
For example, when using vanilla CSS, I often found myself having to change hexadecimal codes through several files because a client may have changed their definition of what “blue” represented. This typically resulted in spending some time searching and replacing the old code for an updated version. With a CSS Preprocessor, rather than searching throughout a document for those codes, you can simply declare a variable @blue (in LESS syntax) within your document and any element referencing the @blue variable will automatically be updated.

@blue: #3498db;
@white: #fff;

h1, em {
  color: @blue;
}

#blue-content {
  background: @blue;
  color: @white;
}

That is just the beginning, however.

Mixins
Similar in context to variables, as a developer CSS Preprocessors offer you the concept of Mixins, or what would be more commonly known as functions. Mixins represent a collection of styles that can be applied to a specific element(s) and can be a very powerful tool for you to use any time that you have elements that share styles.

Consider that you would like to apply a border-radius to several elements throughout your application. A Mixin could be created called “border-radius-whole”, which could then be applied to any element that you would like to have a full border radius.

.border-radius-whole(@radius: 5px) {
  -webkit-background-clip: padding-box;
  -webkit-border-radius: @radius;
  -moz-background-clip: padding-box;
  -moz-border-radius: @radius;
  border-radius: @radius;
  background-clip: padding-box;
}

#my-div {
  .border-radius-whole();
}

#my-blue-div {
  background: @blue;
  .border-radius-whole(10px);
}

Now, you might have seen that I am declaring an @radius variable within the Mixin, in this case 5px. That is a default value that will be applied within the Mixin. You can see that within “my-blue-div”, I am redefining that radius with a declaration of 10px to be applied.

Similarly, you can see that Mixins present a great opportunity to manage cross-browser compatibility issues. Meaning, rather than declaring all of your webkit, moz, IE, etc. overrides throughout your CSS document, you can just define them in one location – your Mixin. This alone is a tremendous time saver.

Nesting
As someone who appreciates cleanliness in code, one of my chief complaints with CSS is that it is very easy for the code to become unreadable and unmanageable. Without the ability to appropriately nest code, developers can find themselves hard pressed to be able to write and maintain clean style sheets. CSS Preprocessors approach this fundamental problem very simply; you can nest your code. It is as simple as that. For simplicity’s sake, what once looked like this:

#my-div { }
#my-div a { }
#my-div a:hover, #my-div a:focus { }
#my-div p { }
#my-div strong, #my-div .important { }

Can now be written as:

#my-div {
  a {
    &:hover, &:focus { }
  } 
  p { }
  strong, .important { }
}

Admittedly, this is as simple of an example as you can come by, but when you work on large scale digital products, as we do here at ITX, maintaining clean, readable code is immensely important and being able to nest CSS is a large part of that process.

Strategy
Arguably the single greatest benefit of using a CSS Preprocessor, is that tools like LESS and SASS provide a foundation for building a strategy to approach front end development. There is no doubt that User Interfaces are becoming more complex to construct and approaching them without a strategy is a mistake. We have found that using CSS Preprocessors to help us maintain DRY (“Don’t Repeat Yourself”) principles from end-to-end within our applications has saved us countless hours. This strategy extends from our files to the code that we write – all in an effort to provide the highest quality with the most efficiency.

You Owe It To Yourself
We are all being challenged daily with new and interesting projects, which require innovative techniques. CSS development has long been a tedious and time consuming exercise and CSS Preprocessors offer a tool that improve upon it tenfold.

Like what you see? Let’s talk now.

Reach Out