Reduce The Complexity of Responsive Web Design Using SCSS

Those who have worked with CSS, know that stylesheets end up being quite large, which becomes cumbersome; as well as the fact you end up writing some styles repetitively. This is very counterintuitive to programmers, who hold fast to Don’t Repeat Yourself (DRY) as one of tenets of programming.

Take this simple scenario: you’re using several different fonts in styling a website, and those fonts are attached to many different elements in many places in the stylesheet. If you need to swap one style out for a different one, for one reason or another (as examples: based on a client request, or the font doesn’t render nicely in all browsers), you could simply do a robust “Find All” in your Text Editor / IDE of choice and replace all of them.

Wouldn’t it make things easier if you only had to change that font in one place and have the changes cascade through? Or what about changing a colour to something slightly darker, or slightly lighter? Or easily switching to a seasonal theme for your website by changing a couple lines of code which change all the colours?

This are simple issues that most people wouldn’t even consider issues at all. Just minor inconveniences.

Enter the age of multi-screen devices, Internet on your TV (or your fridge!), web apps, & responsive web design.

According to Google, 90% of all media interactions are screen-based. Check out their beautifully-presented research The New Multi-Screen World Study.

Well now, things just got a whole lot more complicated, didn’t they? The web permeates our lives.

With so many devices, browsers, screen sizes, device screen resolutions, etc; it gets complicated very quickly in building a website that can serve up good-looking content and, at the same time, provide great user-experience on the multitude of devices and platforms out there. Fortunately, there is a methodology that tackles this overly-complicated scenario: Responsive Web Design (RWD). The main components of RWD are:

1. A Fluid Grid
2. Flexible Media
3. Media Queries

Media queries are really great, but when added together with the default styles of the website you’re working on, they make the CSS that much larger. Back in 2011, I made my first responsive website and my approach at the time (following the quasi-established convention) was writing all the styles for the desktop site, and then treating the @media queries as a totally separate concern; each break-point having it’s own list of changes as shown below in the first code sample.

Code Sample #1

Since that project I’ve learned a lot more about RWD and grown with the movement as it overcame more challenges. Using a fluid grid and flexible media are also part of the challenge, and for dealing with these features I started trying out various responsive CSS frameworks, finally settling on Zurb Foundation.
Zurb’s framework eventually started including SCSS files as they found it a lot easier to make their framework modular and extensible by setting it up with variables and mixins. It was then that I realized I needed to learn SCSS, so I made a point to integrate it into the next website project I was doing. Sass/SCSS is a meta-language extension for CSS, allowing you to use variables, nest selectors, create “mixins” which are reusable snippets of code, and selector inheritance. Sass (Syntactically Awesome Style Sheets) is the older language, and SCSS (Sassy CSS) is the new & improved standard.

Read through this great overview from Zurb of why we should use responsive design is and how using Foundation will help.

SCSS files have “.scss” as their file extension. It usually goes hand-in-hand with Compass which is a plugin full of handy mixins and reusable patterns for dealing with CSS3, cross-browser compatible snippets, and typography. It can also be used to watch for changes in your .scss files and then update the CSS files accordingly. There are several ways to set up your dev environment with Sass & Compass; directly in terminal/command line, or using programs such as Prepros or Fire.app. I started out with Fire.app, but now I use Prepros. Fire.app is handy because it has a few frameworks (Zurb Foundation, 960gs, Twitter Bootstrap) already built-in as Compass extensions, however, it’s better to keep your framework dependencies out in the open, as upgrading your tool (which could be updating the installed frameworks from version 2.5 to 3.1 for example) could potentially break your project.


I highly recommend using Prepros for your preprocessing needs (it also includes Compass and supports a number of meta-languages for HTML templating and rapid JS writing with Coffeescript). Once you have it downloaded and running, simply drag your base project folder into the app. It will watch for any changes in your SCSS files based on their file extensions. I prefer to keep things separate, so I always keep my SCSS files in their own folder. Prepros will detect top-level SCSS files and you can choose which style format to output the CSS files into, such as compressed, compact, nested, or expanded. (Compressed being the ideal choice once the site is ready to go live.)

Digging into the main SCSS folder you can see there are two top-level files on the left. They are the ones that don’t begin with an underscore (“_”). Ultimately you want to output into as few CSS files as you can to keep your HTTP requests to a minimum. The files that begin with “_” are meant to be pulled into another file which is either a top-level file or a file that itself gets pulled into a top-level file.  Code Sample #2, is an example of how your main top-level file would import other files in order for the final output to be one file as “app.css”.

Code Sample #2


As I mentioned previously, it’s smart to keep your dependencies within the project you’re working on, so on the immediate left we have Foundation’s SCSS folders. _variables.scss is the main file that you would edit for using the framework, and the _foundation.scss file is where you can choose not to import certain features. That’s another huge benefit to using SCSS with a framework; you can easily switch off and on which parts to include without having to figure out where one section of code ends and another begins.

In Code Sample #3 you can see Foundation has a lot of SCSS components available, and you can choose which ones to include, based on the needs of your project. Some of these components are for the Javascript plugins that Foundation has built into it. But they are also set-up so that you can choose which ones to remove based on your needs.

On the left we have your main app styles divided up into individual pieces so that you can find what you’re looking for very quickly. It’s up to you how you name these partials, and realistically you want to set it up in such a way that it makes not only to you, but someone else as there’s a good chance another person will need to use the code afterwards.

Here I have the page partials in their own folder and have broken them down into 4 pieces. Mainly you want to break things up into more manageable chunks so that you can concentrate on that section or feature or custom landing page, on it’s own.

Code Sample #3


Features of SCSS with Examples:

Variables – Placeholders so you don’t have to repeat yourself and then can modify a colour, font, etc in one place rather than in 100 or more places. In SCSS the format is a dollarsign (‘$’) before the name of the variable and then what follows the colon (‘:’) defines it. I like to keep the fonts and colours in their own SCSS partials, which are loaded first before most other partials so that you can use the variables and fonts everywhere; and only have to set them, or change them in one place.

Code Sample #4

Code Sample #5 is from the foundation/_variables.scss file, specifically in the grid settings section. This is where we create variables for quick calls to various @media queries. First we specify the breakpoints / content reflow points based on device screen width. Then we put that variable into another variable with the @media query syntax. I’ve added in two extras, using the same format for breakpoints at 640 px and 1600 px as examples for more places you can have your content reflow if needed.

Code Sample #5

Mixins: Code Sample #6 is an example of how to create mixins, which are code snippets that you will re-use many times. It can also be a function that is performed within SCSS that you will call upon more than once. I also make this into it’s own SCSS partial (for example _donsphoto-mixins.scss), which is included shortly after the fonts and variables, so that we can call upon the mixins anywhere after that. Read more here.

Code Sample #6

Now that those variables and mixins are set up we can call them over and again in a much less verbose manner. For example, we declared a mixin above “@mixin spriteDonsPhoto”; to pull this into an element we use @include spriteDonsPhoto as shown in Code Sample #7with the @media queries.

Keep in mind that Foundation 4 is a mobile-first framework, which means any styles we specify will be for mobile, and if we need specific style changes at different screen sizes, we will need to use those variables we set-up for the @media queries to change the styles as the screen size gets larger.

In Code Sample #7, an example from the _header.scss we can also see some mixins being called from Foundation’s SCSS grid. Which are the “@include grid-column(12)” or “@include grid-column(4)”; scroll to the bottom of this page to read more about using this grid with SCSS.

Nesting – Instead of repeating ourselves, we can simply indent our child elements under the parent elements (still using brackets to keep things separate); making our code easier to look at and also making inheritance and scope very clear. See the code example below and then the CSS output as

Media Queries – In concert with the mixins we can use the syntax “@media #{$small}” or “@media #{$medium}” to declare breakpoints in a very easy to follow format. In the piece of code below we can see that this search bar takes up the full width of the screen on mobile, and then when the screen is larger than 768 px at the “@media #{$small}” breakpoint, the search box only takes up a third of the grid.

By specifying the styling changes at different screen sizes directly within the element in SCSS, rather than grouping the media queries into several large media queries (such as the example shown at the start of this blog post), we avoid repeating ourselves by declaring the element’s class or ID in another place. This saves time, as before I would searching and scrolling for code, going back and forth between @media queries declarations.

Having the code in one place makes it very clear what is being applied to tha particular element/class/ID, which makes working with it, handing it off to someone else to work with, or going back and looking at it months later, MUCH easier to deal with. This is a huge benefit to using SCSS for responsive design, and a large part of why I wrote this blog post. Compare the SCSS of Code Sample #7 to the output in CSS as Code Sample #8

Code Sample #7

The above section of the partial _header.scss outputs to the CSS shown below:

Code Sample #8

For a more visual example of how nesting + mixins can be leverage for use with icon sets and sprites, in SCSS take a look at Code Sample #10 & Code Sample #11.

Shown on the left is what the mobile layout looks like, with the help button hidden and menu Navicon displayed on the left.

On the right we have the tablet & desktop version of the buttons with a hover state activated on the “Stores” button. The “Cart” button is not included in the example SCSS code below as it has a few of it’s own rules and colours. The following code demonstrates how much easier it can be when working with sprites and UI elements and using SCSS.

Code Sample #9 shows the HTML (with some PHP sprinkled-in from Magento) structure of the icon buttons, so that you can see how it all works.

Code Sample #9

Code Sample #10

The above SCSS outputs to a much longer version in CSS:

Code Sample #11