Please fill out this short survey before we get started!

Choose your own Refactoring Adventure

A workshop at SassConf 2014
by Elyse Holladay & Jina Bolton


Dev/Designer, Instructor, MakerSquare


Senior Product Designer, Salesforce UX

“I always code perfectly
the first time!”

—Some Liar

Clarity · Maintainability · Efficiency · DRY


Code should be clear, well-commented,
and follow consistent rules. A developer new
to the project should be able to understand it.


Code should be easy to update & maintain,
not requiring hacks or over-specific styles.
It should be clear where files and styles belong.


It should be easy for a developer to find
where styles live, write new styles, fix bugs,
or find documentation and instructions.


Don't repeat yourself! Code should
be reusable, have efficient selectors,
and not be overly repetitive or nested.

But what if
  • we didn’t write it perfectly the first time
  • lack of clarity
  • hard to maintain
  • new requirements
  • design or UI needs to change
  • duplication or bloat
  • code smells


changes the structure of existing code
without changing its behavior


supports the process of change


makes code easier to modify
and maintain in the future

getting everyone
on the same page

Why we Don’t refactor

  • your team doesn’t understand how
  • long-term benefits aren’t worth immediate effort
  • overhead; you’re paid to write new features
  • it might break something

Why Sass helps
with refactoring

Systems, not Pages

  • separation of concerns
  • importing files, folder structure
  • variables
  • mixins and extends
  • nesting and namespacing

Make refactoring a regular part of your workflow.

“Sass is not a replacement for CSS, it’s more like having a CSS assistant who will help you write your code.”

— Tom Genoni

Installation & Apps

Goal: Determine the best way to use Sass in your project.

I have to use the
command line!?

gem install sass

sass --watch /path/style.scss:/path/style.css

10× speed improvement

2.5 seconds down to 0.2 seconds


➼ Grunt for People Who Think Things
Like Grunt are Weird and Hard

by Chris Coyier

.scss or .sass?

Goal: Choose a syntax for your project.
Steps to switch to .scss
  1. change all your .css files to .scss
  2. compile your code
  3. Open your site in a browser

Sass has two syntaxes

* the language name! It’s not an acronym!

SCSS* or “Sassy CSS”

Looks just like CSS.

Every .css file is a valid .scss file.

  .widget {
    color: #fff; /* CSS works here */
    background: $backgroundColor; /* but so do Sass variables */
    margin: 20px;
    padding: 20px;

* it's an acronym!

.sass syntax uses indentation rather than brackets to indicate nesting of selectors, and newlines rather than semicolons to separate properties.

  .widget /* look ma, no brackets or semicolons! */
    color: #fff
    background: $backgroundColor
    margin: 20px
    padding: 20px

  // you can use shorthand includes
  =large-text // instead of @mixin large-text
    font-size: 20px
    color: #ff0000

    +large-text // instead of @include large-text

Converting .(s)css to .sass

  /* SCSS using indentation as relationship */
  .nav {
    styles: go here;
  .nav-item {generic: styles;} // indented under .nav but NOT nested

  // .sass syntax uses indentation as nesting
    styles: go here
    .nav-item // now will output as .nav .nav-item
      generic: styles // now are possibly not generic anymore


Goal: Choose how to import and organize your code.

Create a manifest file.


  @import [framework or vendor css]
  @import styles.scss

break up existing files
& import them

Break out related sections of code,
e.g. errors/messages, buttons, icons, nav, etc.

Make a new file for each with a comment
explaining what is in the file.

Keep files small and readable.

import without altering
existing CSS output order

Re/organize files & folders

Creating Variables

Goal: Create simple, new variables that don’t alter output.

Switching to variables

cmd(+opt)+F in Sublime Text is your new BFF.

  1. Make a new file: variables.scss
  2. Make a new variable: $white: #ffffff;
  3. Search for all the #ffffff, #fff, #FFF, white, maybe even #f9f9f9.
  4. Replace them with $white
  5. Now do the rest!

Import variables.scss into your manifest first.

Use color operations
for variations.

  $dark-purple: darken($purple, 20%);
  $light-purple: transparentize($purple, 20%);

Typography Variables

  $font-headline: "Proxima Nova Bold", "Calibri", Arial, sans-serif;
  $font-body: "Calluna", "Cambria", Georgia, sans-serif;

  body {
    font-family: $font-body

  h1, h2, h3, h4, h5 {
    font-family: $font-headline;

Variable Abstraction

Goal: Clarify variable names, create themes, named media queries.

Shared Name First

  // by shades...                       // better: by shared name
  $blue;                                $blue;
  $medium-blue;                         $blue-medium;
  $dark-blue;                           $blue-dark;
  $darkest-blue;                        $blue-darkest;
  $light-blue;                          $blue-light;
  $lightest-blue;                       $blue-pale;

Abstracted Variable Names

Creating Simple Themes

Named Media Queries

Organize Files & Folders

Goal: Keep style, vendor, and helper code separate;
make files easy to find and not cluttered.

config: settings, variables

themes, if you have any

helpers: mixins, JS state classes, CSS3

frameworks: foundation, bootstrap, grids

components: icons, buttons, page components like header/footer

modules/base: your semantic HTML - page content, not elements like buttons

IE or responsive if you keep it separate

vendor: third party libraries, JS

Configuration Files


Mina Markham’s Sassy Starter


Creating Modules

Goal: determine what modules your project has & how to group them

What modules do you have?

How do you determine in your old code
what is the same and what is different?

Print your website out!

Namespacing Modules

& parent selector
State Classes
Namespacing Modules

@include duplicates CSS

use when you need to alter variables

@extend comma-delineates selectors

reuse code with no extra output

%placeholder extend takes this one step further,
and eliminates the output for the original ruleset.

where do you put new modules?

It's okay to refactor your folder
structure as your project grows.

Steps to Refactor

Goal: take your modules and do the actual refactor work!

Chris Eppstein, “Refactor My Stylesheets:
The Edition”

1. Extract partial
2. Find repeating patterns
3. Create/Extract Base Class/Extend
4. Apply/Remove Nesting
5. Edit HTML Classes
6. Apply Variables
7. Create Mixins

1. Extract Partial

2. Find Repeating Patterns

Repeating Patterns

  • selector duplication that implies inheritance relationship
  • repeating patterns relating to colors, typography, etc
  • complex nesting or selector chaining

Repeating Patterns

  • a CSS class that can function as a consistent base class
  • plain ol' duplicated CSS of any type
  • states (active, disabled, etc) that should be combined
  • IDs or classes for JavaScript that may also have styles

3. Create/Extract Base Class/Extend

4. Apply/Remove Nesting

5. Edit HTML Classes

6. Apply Variables

7. Create Mixins


125 lines to 85 lines

"But the biggest win is that adding a new kind of feedback requires only 1 or 2 points of edit instead of the 5-7 that would have been required before. This is, without a doubt, more maintainable..."

— Chris Eppstein
1. Extract partial
2. Find repeating patterns
3. Create/Extract Base Class/Extend
4. Apply/Remove Nesting
5. Edit HTML Classes
6. Apply Variables
7. Create Mixins

Naming Conventions

Goal: Choose a naming convention that works for you.

Whatever you do, be consistent:

.section, .section-item, .section-item-thingy


Organizing Properties

alphabetical, by property type, camelcase vs underscore vs dashes

Living Style Guides

Goal: Keep your styles maintainable, consistent, & visible

Style Guides are all the rage

…and they have come a long way.

  • PDFs are a pain to maintain.
  • Online is easier to update.
  • Living on your app is better.
  • Automated is even better.
  1. Design & Brand Standards
  2. Front-end Development Standards
  3. Keeping Style Guides Current & Useful

The key is

“Current & Useful”

Once the style guide is not up-to-date, it is no longer useful.

Sass + Style Guides = Awesome!

What if a color gets added?

You need to update the style guide, too.

Automated Style Guides

  • KSS
  • StyleDocco
  • Kalei
  • …etc.

These are pretty great for quickly getting docs up & running.

Manual Creation

gives you flexibility

…but you have to stay on top of it.

I like a hybrid approach.

Documentation &
/* Commenting */

Goal: have a consistent comment style and use it!
  • Comment each file to explain what is in it
  • Comment every large section of CSS
  • Comment individual items that need clarification
  • Be consistent
  • inline comment documentation

    keep it up to date when you change your code.
    // Single-line JS-style comments don't need a closing tag,
    // and they are hidden from your compiled output! This is
    // great for inline documentation about the styles themselves
    // and how they should be used, mentioning hacks, or TODOs.
    /* CSS style comments can be multi-line with a closing tag
    and they appear in your compiled output. This is great for
    section documentation and headers/dividers! */

    Write instructions in comments.


    Goal: Don’t be breaking shit.

    DiffUX, Wraith, Huxley


    Keep refactors small so they don’t break things

    …or simply overwhelm you.

    What’s right for
    my project?

    Thank You!

    @elyseholladay + @jina