Sass for Designers

Despite saying that I wanted to avoid writing post about development, I wanted to write something about Sass.

Excuse me, what is Sass?

Sass is a CSS pre-processing language; it’s a slightly different way of writing CSS which can then be processed by a tool that spits out fully-working CSS. It’s like a kind of short-hand that adds in some handy features that aren’t available in CSS. If you want to know how to use Sass in your workflow, try my post on Sass for Designers — The Setup.

Why am I writing this?

Sass still isn’t particularly easy for designers to pick up straight away. The documentation isn’t easy to understand, The way it’s written is really aimed at those more familiar with programming. The tutorial isn’t too bad, but it doesn’t tell you about the advantages from a designer’s point of view.

I want to just cover a few simple principles. I’m no Sass expert, I use mostly it in its simplest form, but I’ve found it incredibly useful.

So what are these advantages? It’s all about efficiency. It makes your markup quicker to write, less repetitive and easier to maintain. That might sound a bit performance-related, but I promise that it’s something that designers (we who use markup to support our design work, rather than being super-programmers) can use to make development much more straight-forward.


The best and most basic example is variables. We tend to use the same colours throughout the document. This result in us writing the same hex code or RGB value over and over again. If we want to change that colour, we need to do a Find-and-Replace to pick through all of our markup, making sure we don’t accidentally change the wrong value. You might have a few rules that each need your dark red brand colour:

Using variables, we can give that particular red hex colour a variable name of $brand-colour at the beginning of our stylesheet, and then just use that variable throughout the stylesheet where we’d usually use the hex colour. Then, if you suddenly decide that the shade of red isn’t quite right, you just need to change where you declared $brand-colour: #822733; at the top, and it will be changed for every rule that uses the variable throughout the whole stylesheet.

Numbers as variables

Variables don’t just have to be strings of text, they can also be numbers which you can manipulate. If you use some kind of baseline grid idea, modular scale, or just a pattern of numbers to keep your design proportional, chances are you’re frequently repeating the same values throughout your stylesheet. If you were using 10px measurements all over the place, you might create ‘unit variable’ with $unit = 10;. This unit could then be repeated:

But how about when you want that unit to be doubled? You want exactly twice the margin on another element, because then it will still keep the rhythm in your design. With Sass, you can add simple maths (+, -, *, /, %) to do this very simply:

Then if you decide, one day, that multiples of 10px aren’t big enough for your design (need MOAR WHITESPACE) then you can just change your $unit variable to something bigger, such as $unit = 15; and all of your measurements will be changed accordingly, preserving those proportions throughout your stylesheet.


Mixins are reusable collections of rules. These are perfect for design patterns that you might use throughout the site. These also stop you repeating yourself in your CSS but in a way that’s more semantic than using the same class name on every HTML element.

For example, you might have particular divider style that you use all over your site. You use it below all sorts of elements; <article>s, <header>s and even the odd <p>. It’s got a certain amount of padding between the border line and the content above, and a certain margin below. It’s just a grey border but it has a fancy shadow on it.

a grey border line with a subtle grey box-shadow

an example of what your divider with a subtle border might look like

Then you might apply the following CSS class of .shadow-border to any HTML element you want to have the divider. It’s not very semantic, but it does the job:

If you wanted to be more semantic, you might go applying all those rules to all the relevant HTML elements, but this can make for an awkwardly-organised stylesheet.

With mixins, you can give this collection a name using @mixin. This name doesn’t have to relate in any way to your HTML:

Then, to apply that mixin to any element, you just include its name @include shadow-border; like you would any other rule in CSS.

Doesn’t that look neat and tidy?!

Nesting mixins

Even better, you can nest your mixins inside other mixins. We might want to apply that same type of shadow to lots of elements, so that our design appears to have a consistent light source throughout the site. So we then make a mixin especially for that shadow too. This has the added bonus of keeping all the prefixed CSS (-webkit, -moz, -o, -ms etc.) tucked away in one place too.


Mixins aren’t the only thing you can nest in Sass. You could nest tags within each other if you wanted, which makes your CSS less repetitive and easier to read as you can see which selectors are related:

But let’s face it, that’s getting really nit-picky about the neatness of your CSS.

Nesting @media

Where nesting becomes incredibly useful is with media queries.

If you follow SMACSS or any other school of thinking where you’re trying to base your media queries around the optimum display of your content, rather than the viewport width of various popular devices, then chances are your stylesheets are filled with different media queries trying to keep your site looking tidy at every possible width.

Nesting media queries can help with this. Where previous you may have felt like you needed to keep all your media queries in separate files (one for 320px and up, one for 768px and up and so on…) Group all selectors using the same media query width together or list all your media queries relevant to a selector one after the other. Sass allows you to nest your media queries within the selector so you can easily spot where those breaking points are and where they need to be changed.

For example, I have an article which has a changing width, line-height and font-size depending on the width of the viewport. I want the text of my article to be as legible as possible across all devices. In CSS, this might look like this:

When you can include the media query within the selector, it suddenly becomes a lot easier to find those rules that you’re so likely to tweak in the future.

Give it a go?

There are so many clever, time-saving, efficient things you can do with Sass, and I certainly don’t know them all. The benefit of writing Sass is that you can just write everything in plain old CSS, and just use Sass on the few selectors that could really benefit from it. That’s how I got started, and on every new project I work on, I learn another handy tip and make my CSS that much quicker to write.

If you’ve got any tips, please let me know in the comments as I find it really hard to discover what might be useful when you’re writing markup with a designer’s perspective!


  1. Nested media queries just about brought me to tears… Hey, you have $unit = 10; That should be $unit: 10? I couldn’t find anything in Sass nor SCSS that looks quite like that.


  2. John Harrington

    Nice article, but I don’t like that use of mixins very much, that style is just being duplicated everywhere and I really think you’d be better with a class for it, to reduce the bloat in CSS.
    Mixins are best used when you need to calculate things, for instance I use this little mixin to quickly set font sizes and line heights:

    font-size: $size + em
    @if ($size >= 2)
    line-height: 1.5em
    @media screen and (min-width: 30em)
    line-height: 3em
    line-height: 1.5em

    (also, I use the Sass syntax, rather than SCSS, because I love the whitespace)


  3. John Harrington

    For mixins you would actually be better off doing the example where the CSS was badly organised because Sass won’t recognise that the same styles are being applied on each, so your CSS will end up bloated.


  4. Funny enough, it was this article by Nathan Smith with the same name as this article here that convinced me about using SASS in the first place:

    (And I have a programming background :-)


  5. A useful complement to @include is @extend. While @include duplicates the mixin rules for each class, @extend has the classes share a single instance of the rules. This helps with the CSS bloat that John mentions.


  6. A useful complement to @include is @extend. While @include duplicates the rules for each class, @extend causes them to share the rules they have in common. Helps with the CSS bloat.


  7. dtgreen

    Brilliant read Laura. I’ve been trying to find the time to jump into SASS lately, and this article has pretty much made up my mind: I’m going to dive in this weekend! :)


Leave a Comment

Your email address will not be published. Fields marked with * are required.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>