Sass Mixins to Kickstart Your Project

Mixins are great, aren’t they? They are like functions that output CSS. According to the Sass docs:

Mixins allow you to define styles that can be re-used throughout the stylesheet without needing to resort to non-semantic classes like .float-left. Mixins can also contain full CSS rules, and anything else allowed elsewhere in a Sass document. They can even take arguments which allows you to produce a wide variety of styles with very few mixins.

Mixins are really convenient, especially when working on a large project. How many times have you had to define width and height values in your last project? How many times have you Googled how to do a triangle in CSS? Or haven’t you ever wished there was a shorthand for top, right, bottom, left when using CSS positioning?

You can solve all those problems with mixins. Even better: you won’t have to write them since I’ve already done that for you. Here we go guys, a couple of Sass mixins to kickstart your projects!

Sizing Mixin

I bet you already know this one. I use it as a mixin 101 in all my projects: a size() mixin defining both the width and the height. First argument is the width, second one is the height. If height is omitted, it falls back to the width value.

Example Usage

Positioning Mixin

If there is one shorthand I really think CSS misses, it’s a shortcut for offsets: top, right, bottom and left. We have shorthands for everything: padding, margin, background, even text-decoration! But we still don’t have one for offsets… So I built my own.

It was inspired by Stylus’ syntax:

absolute: top 0 left 1em

Unfortunately, Sass doesn’t provide a transparent mixin feature so, at best, we can come up with something like this:

@include absolute(top 0 left 1em);

… which is not that bad, you have to admit. Obviously we’ll also have relative() and fixed() which work the same way.

I dedicated a whole blog post to the making of this mixin so I won’t get too deep into details here, but the main idea is to provide a list of values to the mixin. Whenever a keyword is found (top, right, bottom, left), the value directly after the keyword gets applied to it, as long as it is a valid value.

Vendor Prefix Mixin

You know how you have to prefix some properties with -webkit- or -moz- (among other prefixes) for them to work across browsers because they are non-standard properties? Then you also know how annoying that can be. This is precisely the type of thinking Compass and Bourbon try to fix by providing a collection of mixins dealing with prefixes for you (e.g. @include box-sizing()).

I have been using Compass for long now but I have recently decided to ditch it. The main reason is I wasn’t using it enough to keep it in projects; in the end, this means faster compilation times. That being said, I found myself in need of vendor prefix mixins. So I built one (and updated it when moving to Sass 3.3).

Sass 3.2 Version

The idea is very simple. The first argument is the property. The second argument is the value for that property. Third and optional argument is the list of prefixes to use. Default value dumps all prefixes.

Example Usage

Sass 3.3 Version

My Sass 3.3 version is even better because it allows you to prefix multiple properties at once, and to have a nicer syntax. Basically, instead of having two distinct arguments for property and value, you have only one: A map of declarations. Keys are properties, values are values.

Opposite Direction Mixin

If you’re a user of Compass, you may be familiar with the opposite-direction function (yes, this one is a function and not a mixin, but whatever). The one from Compass is built in Ruby but it’s quite easy to make a Sass one. The one I made relies on Sass 3.3 but it can easily be tweaked to be available to Sass 3.2.

What I like in my function is it allows you to pass a list of directions, so that you get bottom left from opposite-direction(top right). It can be useful when dealing with background-position, for instance.

Example Usage

Breakpoint Handler Mixin

If you’ve ever had to do some responsive design, you know working with several different media queries can be hard. It’s often a good idea to store the various breakpoints in variables so they can easily be retrieved without having to be typed all over again every single time.

If you want to take it a step further, you might want to name your breakpoints — which is a very good idea if you want my opinion. This basically means a media query is mapped to a name so you only have to give your breakpoint handler mixin a name to make it dump a media query. Many smart developers including Chris Coyier have made the idea quite popular.

Now if you want to go even further, you can store all those breakpoints in a global map, then make the mixin retrieve the breakpoint based on the name you pass it. Please consider the following code:

If the string passed to the breakpoint mixin matches a key in the $breakpoints map, the mixin opens a @media directive, using the inspect function (from Sass 3.3 as well) to literally dump a map. When doing inspect((key: value)), (key: value) gets printed as is in the stylesheet.

If the string doesn’t match an existing breakpoint, then the user gets warned through the @warn directive, printing an error message in his console.