An Event Apart: Preprocessing is for Everybody

While attending An Event Apart San Francisco in December 2013 I watched Chris Coyier give a talk about CSS preprocessing and the powers they holds. Moreover, he gives some great tips on how to convince the “Grumpy Greg” at your office that doesn’t want to learn. Here are my notes from his talk, Preprocessing is for Everybody.


  • Quick lesson about binary and the meanings taken from the 1s and 0s.
  • We created languages (C, C++, HTML) to make talking to the binary easier.
  • When things get too complicated (over time?) we hit an abstraction point. Creating another abstraction – Sass in this example – we are able to manage that complexity.
  • Browsers continually do more complex tasks, we need to be able to develop a process to build for them.
  • Weird attitude from some: “I’m willing to use these [abstracted] languages, but… I will go no farther!”

How Preprocessors Can Help You

  • Sass is an abstraction, just one more step away from the 1s and 0s.
  • CSS is the last in line to get this treatment.
    • HTML has server/client side templating engines.
    • JS has build in abstractions.
  • Separate styles into multiple .scss files that get compiled into one CSS file (reset, colours, forms, typography, etc.).
  • CSS turns into “robot barf” – which is more beautiful than it sounds.
  • Browsers fly through it because that’s how they expect to see information, not some human-readable formatted file.


  • Basic colours, spacing units, font stacks, etc.
  • “Variables don’t help you not be an idiot, but they make those moments com up less.”


  • It’s more than saving keystrokes, it makes it easier to see what’s related.
  • Media queries used to be chunked together at the bottom, creating a huge disconnect between relevant code. Sass lets you nest queries within elements.
  • Or, use a mixing like “if wider than ___ do ____”
    • @include wider-than (baby-bear{ width: 25% }
    • Readable, clean code


  • Way easier to handle vendor prefixes
  • Can use things like Compass or custom mixins to add them for you
  • Or use an autoprefixer during your build process so you don’t have to worry about prefixes at all


  • No need for a ton of classes on element. (ie. btn-primary btn-large btn-blue).
  • Comma-separated selectors to create more efficient writing and production code.
  • If you’re using a mixin with no parameters it’s probably best to use an extend.

Placeholders (silent mixins)

  • Used for something like a clearfix or grids.
  • Can use more relevant class names that extend the placeholder class.

Convincing the Team

  • Sass simplifies development and lowers the complexity of our site.
  • Let’s make things easier, not harder.
  • It’s a one time cost. Learn it once and use it forever.
  • One main goal is to help with consistency across the team.
  • Site performance is an issue, and we’ll have compressed styles by default.
  • Short learning period, can slowly dip your toes in, and back out if necessary.
  • All .css is already valid .scss, just change the extension.

Transitioning to Sass

  • Get started very easily.
  • Nest some related selectors.
  • Change colours to variables.
  • Mixins (or autoprefixer) for vendor prefix management.

Common Misconceptions

It complicates my workflow

  • One time setup, long time benefits.
  • Apps help to speed up dev like livereload / style injection.
  • Writing Sass can be easier (and faster) than CSS.

Am I all in?

  • Sass can export indented, commented code so you can always revert to CSS.

It causes bloated output

  • No, you wrote bloated code.
  • Little to no performance penalty for repetitive media queries.

Sass is only for big sites

  • Just because your site is small doesn’t mean you don’t care about development speed, prefix issues, code readability, etc.

I have to learn a whole new syntax? What about my whole team?

  • It’ll take you about an hour. Same with everyone on your team.
  • Your team will be able to work together easier.

Sass features will eventually be integrated to CSS

  • Even if it does, it’ll be years before you can use it without thinking about the fallbacks.

Harder to debug with line number reference in dev tools

  • Source maps is solving this in Sass.
  • Since your .scss files are more organized already, this issue doesn’t come up as often.

Preprocessors are a part of the new school process already. It’s the current generation that needs to be convinced.

6 comments on “An Event Apart: Preprocessing is for Everybody

  1. Chris December 10th, 2013
    at 3:33 pm


    Yes, lets go from CSS, something simple that a designer can use, so SASS, something complex that takes a proper programmer.

    I feel like this industry changes sometimes just for the sake of it.

    There is nothing unreadable or hard about CSS.

    Why make needless complications?

    • Veronica December 10th, 2013
      at 4:48 pm


      Sass isn’t so complex that it requires a “proper programmer” to do (by the way, what’s a “proper programmer” anyway?).

      I’m a designer and I’ve recently started working with Sass and it’s really not as complicated as you would think. Have you actually given it a shot? You can even look into SCSS (Sassy CSS), which I think is a really good bridge for learning. Essentially, it just makes the process faster. You’re not writing the same snippets of code over and over again, but the output is compiled to look the same as if you were to write it all our yourself.

      All CSS is valid Sass, so you can start small and learn your way into it. (for example, you might want to start with simply using variables).

      It’s really just a tool that helps make CSS faster to write. Why would you plow the field by hand when a tractor can make the same job more efficient?

  2. Daniel December 13th, 2013
    at 10:06 am


    I’m excited to start using SASS, but unfortunately my organization uses an enterprise CMS that does not support it…

    I think SASS is great because like Veronica says, “it’s really just a tool that helps make CSS faster to write”, and also easier to maintain.

    • Emily Young December 19th, 2013
      at 5:35 am


      The company I work for use a closed source Enterprise CMS, Drupal, WordPress and Umbraco. In all four we have been able to make use of Sass.
      It isn’t down to the CMS to support it.
      Take a look at Grunt.js or similar build tools.

Leave a Reply