Never Repeat Yourself: A Development Technique in Practice from An Event Apart

July 20, 2012

Getting excited about the newest web tools and techniques is something every front end developer can relate to and after attending An Event Apart, Boston, we could hardly wait to turn up the volume on some of our development practices, in this instance, preprocessing our CSS. There are multiple ways to preprocess CSS or Cascading Style Sheets but two most popular are SASS & LESS.

For those still unsure what SASS is exactly:

“Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin.”

- SASS website (

So what’s it good for?

Both languages, SASS and LESS, were created for the same reason: to cut down on stylesheet repetition. After researching both languages we ended up choosing SASS over LESS, primarily because SASS can be processed and output locally as a standard CSS file, whereas LESS uses Javascript to render the standard CSS file in the client’s browser. That’s not to say that LESS can’t be rendered server side with node.js or another similar plug-in but for simplicity’s sake we found SASS’s ability to render an editable, malleable CSS file a deciding factor - this way, while rolling out this new technique, we could spot check the output to make sure the SCSS authors and the compiler are all on the same semantically styled page.

Because this project did not require Ruby on Rails, our SASS development process is a little more creative, though still very manageable. Here at OHO, we are using a combination of Expandrive to mount the server and CodeKit as our local SASS processor/compiler. This solution has worked with great results as we have the best of both worlds: the ability to develop on live servers without the need for Ruby and a set of standard style sheets we can review should we need to take a closer look at the compiled results.

One of the biggest benefits from this approach we’ve found is the the ability to create variables. These variables can be as simple as setting all your brand colors prior to starting a new project as shown in the following example, or as complex as creating variables for specific RWD media queries. So, the following lines show an example of preset color and border variables that we are using in a current project:

$blue: #0040FF

or entire sets of property declarations:

$border-grey: 1px solid #C0C0C0

Using variables simplifies the need to continually add a specific hexadecimal value to each element every time you need it. Not only does it make this process somewhat modular, but it removes the risk of user error. Additionally, because this color value is now available as a variable in one set location, global updates to your colors or other features becomes one line or code, rather than spending time finding and replacing values in the stylesheet. Instead of changing every instance of your color, a change to a single variable will be reflected across the entire stylesheet.

Variables are great, no doubt about it, but the most valuable feature above all others has been the use of SASS Mixins.

“…mixins allow you to re-use whole chunks of CSS, properties or selectors. You can even give them arguments.”

- SASS Website (

For an example of how mixins are streamlining our development process, look no further than vendor specific prefixes. Rather than remember each vendor prefix for a gradient, for example - and there are about a half dozen - we can list all declarations for our gradient values in a single Mixin. These gradients come in a variety of colors and are used on different element types. This time consuming task has been achieved over the years by using a combination of sprites and repeating background images. But now with SASS & CSS3 we’re able to create reusable blocks of code that can be shared across the entire development team, and wrapped neatly into a single Mixin that can be added to most elements properties.

So this:

@mixin black-gradient {
background: rgb(113,113,113); background: -moz-linear-gradient(top, rgba(113,113,113,1) 0%, rgba(0,0,0,1) 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(113,113,113,1)), color-stop(100%,rgba(0,0,0,1))); background: -webkit-linear-gradient(top, rgba(113,113,113,1) 0%,rgba(0,0,0,1) 100%); background: -o-linear-gradient(top, rgba(113,113,113,1) 0%,rgba(0,0,0,1) 100%);
background: -ms-linear-gradient(top, rgba(113,113,113,1) 0%,rgba(0,0,0,1) 100%);
background: linear-gradient(top, rgba(113,113,113,1) 0%,rgba(0,0,0,1) 100%); filter: progid:DXImageTransform.Microsoft.gradient( startColorstr=‘#717171’, endColorstr=‘#000000’,GradientType=0 );

Becomes this:

#nav {
@include black-gradient

Much more sensible, no?

Using CSS variables and mixins is a great way to speed up development time and to share reusable snippets of code across your development teams. Another example of how adding SASS to your development workflow will save time can be found when developing with a repository like GIT or Subversion. Because SASS and SCSS files are preprocessed multiple files can be included within one another and the compiled output will still be a single file. One instance would be to share a SASS file dedicated entirely to mixins that can be shared among all the developers on a large scale project. That way all colors, fonts, gradients, resets, etc. are uniform for all the developers who have included that file in their own stylesheet. Sound complicated?

Here’s the code we use to include all of our compiled mixins between developers:

@import "mixins"

These tips didn’t take long to discover and we’ve only recently rolled out SASS so we look forward to taking advantage of its many features in future projects. That said, we encourage you learn more about LESS or SASS and decide for yourself. Nesting in particular is an interesting feature in-and-of itself as browsers like Google’s Chrome have started to support some of this basic functionality. Will this be the future of CSS, and if so, how modular can each piece of markup become? Only time will tell.

Until next time, happy coding.


Related Reading

Making the Case for Personalization to Non-Technical People

“I’m not a technical person” is perhaps my least favorite excuse for avoiding new tools and trends.

Highlights from DrupalCon 2017

Each year, thousands of developers, designers, content strategists, and industry leaders gather at DrupalCon to share their ideas and experiences using one of the world’s most popular open-source c

The New Typical Student: How Three Schools Are Courting Adult Learners and Winning the Enrollment Game

The American Marketing Association (AMA) Symposium for the Marketing of Higher Education is an opportunity for marketing leaders to come together to discuss strategies and the direction of the high

How to Get the Most out of a Higher Ed Web Conference

It’s the most wonderful time of the year! That’s right, it’s conference season.