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.
Variables
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:
a {
color: #822733;
}
.summary {
color: #822733;
}
.copyright {
color: #822733;
}
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.
// My Sass colour library
$brand-colour: #822733;
a {
color: $brand-colour;
}
.summary {
color: $brand-colour;
}
.copyright {
color: $brand-colour;
}
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:
$unit = 10px;
h1, h2, h3 {
margin-bottom: $unit;
}
p {
margin-bottom: $unit;
}
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:
$unit = 10px;
h1, h2, h3 {
margin-bottom: $unit;
}
p {
margin-bottom: $unit;
}
aside {
margin-bottom: $unit*2; /* 20px */
}
footer {
margin-top: $unit*4; /* 40px */
}
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
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.
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:
.shadow-border {
border-bottom: 1px solid #a4a4a4;
-webkit-box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
padding-bottom: 20px;
margin-bottom: 40px;
}
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.
header, article, p.intro {
border-bottom: 1px solid #a4a4a4;
-webkit-box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
padding-bottom: 20px;
margin-bottom: 40px;
}
With mixins, you can give this collection a name using @mixin. This name doesn’t have to relate in any way to your HTML:
@mixin shadow-border {
border-bottom: 1px solid #a4a4a4;
-webkit-box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
padding-bottom: 20px;
margin-bottom: 40px;
}
Then, to apply that mixin to any element, you just include its name @include shadow-border; like you would any other rule in CSS.
@mixin shadow-border {
border-bottom: 1px solid #a4a4a4;
-webkit-box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
padding-bottom: 20px;
margin-bottom: 40px;
}
article {
@include shadow-border;
}
header {
@include shadow-border;
}
p.intro {
@include shadow-border;
}
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.
// A few variables thrown in for good measure
$border-colour: #a4a4a4;
$unit: 10px;
@mixin subtle-shadow {
-webkit-box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
box-shadow: 0px 2px 5px 0px rgba(200, 200, 200, 0.6);
}
@mixin shadow-border {
@include subtle-shadow;
border-bottom: $unit/10 solid $border-colour; /* Base unit divided by 10 = 1px */
padding-bottom: $unit*2; /* Base unit multipled by 2 = 20px */
margin-bottom: $unit*4; /* Base unit multipled by 4 = 40px */
}
article {
@include shadow-border;
}
header {
@include shadow-border;
}
p.intro {
@include shadow-border;
}
Nesting
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:
/* written in plain old CSS */
.module h3 {
font-weight: bold;
}
.module p {
padding-bottom: 10px;
}
/* written in Sass */
.module {
h3 {
font-weight: bold;
}
p {
padding-bottom: 10px;
}
}
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:
/* initial rule for all viewports, including browsers that don't support @media */
article {
font-size: 14px;
line-height: 25px;
}
article h2 {
font-size: 18px;
padding-bottom: 15px;
}
/* for 300px viewports and wider (mobile first) */
@media only screen and (min-width: 300px) {
article {
line-height: 20px;
width: 90%;
}
article h2 {
padding-bottom: 10px;
}
}
/* for 600px viewports and wider */
@media only screen and (min-width: 600px) {
article {
line-height: 25px;
width: 80%;
}
article h2 {
padding-bottom: 15px;
}
}
/* for 900px viewports and wider */
@media only screen and (min-width: 900px) {
article {
width: 60%;
}
}
/* for 1200px viewports and wider */
@media only screen and (min-width: 1200px) {
article {
font-size: 16px;
line-height: 30px;
width: 50%;
}
article h2 {
font-size: 21px;
line-height: 35px;
padding-bottom: 20px;
}
}
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.
article {
font-size: 14px;
line-height: 25px;
h2 {
font-size: 18px;
padding-bottom: 15px;
}
@media only screen and (min-width: 300px) {
line-height: 20px;
width: 90%;
h2 {
padding-bottom: 10px;
}
}
@media only screen and (min-width: 600px) {
line-height: 25px;
width: 80%;
h2 {
padding-bottom: 15px;
}
}
@media only screen and (min-width: 900px) {
width: 60%;
}
@media only screen and (min-width: 1200px) {
font-size: 16px;
line-height: 30px;
width: 50%;
h2 {
font-size: 21px;
line-height: 35px;
padding-bottom: 20px;
}
}
}
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!
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:
(also, I use the Sass syntax, rather than SCSS, because I love the whitespace)
(And I have a programming background :-)