Grow your CSS skills. Land your dream job.

Musings on Preprocessing

Published by Chris Coyier

I've been using SASS for pretty much everything I do recently. Here's some musings on the journey. From hold-ups, to trip-ups, to turn-offs. From apps and teams to workflows and syntax.

You Gotta Work Locally

The biggest contributor to me getting on the bandwagon was giving up my going-commando live FTP editing ways. Yeah, Coda is awesome, but it's bad habit forming. It makes it way too easy to work live instead of local1.

Working local is full of obvious advantages. Namely, 1) It's fast 2) You can edit stuff to your heart's content without worry you're screwing up a live site and 3) It allows you to effectively work on a team through version control (more on that later).

So just do it. If you work only on static sites, you can just start doing it. Work from a folder somewhere on your machine. If you work on PHP sites (e.g. WordPress, Joomla, PHP, Vanilla, CodeIgnitor, CakePHP, and a million more) then using MAMP (my screencast) is ideal. Of course there are variants of MAMP for all platforms.

If you are using something like Ruby or Python, well, chances are you know how to set up that stuff anyway so you're fine.

Now that I'm working primarily on projects that run on my local machine, using preprocessors is easy. I use a couple fantastic apps that I'll cover later.

Command line blah blah blah

I'm a designer! I don't know how to use the command line nor should I need to.

That's a very common thing to hear regarding SASS. Here's the thing: I'm right there with you. I hate the command line. You don't need to. I don't, nearly ever, for anything2.

Other turnoffs

As childish as this may seem, another reason it took me so long to get on the preprocessor bandwagon was the crowd. And I'm not alone here.

It's hard to say anything at all about preprocessors, let alone something vaguely negative, without getting pounced on.

For a long time I thought: I write CSS everyday. I know CSS pretty well. My workflow is fine. I'm productive. Why does anything need to change?

The real answer is that nothing needs to change if you don't want it to. If you're perfectly happy doing what you are doing: godspeed.

I can tell you that after making the jump, I am actually more productive. And I write better CSS. And the projects I work on are in better, more maintainable shape because of it. And in some cases, faster3. My advice is: don't let people get on your case. Just do what you gotta do. If you get some time to try it out, do it. And do it on a real project. Just tinkering around doesn't count. You gotta really try it to see how it might work with your day to day.

The Apps

I only have experience with Mac apps. Sorry. I'm sure there are pretty good ones for other platforms.

The app that got me started on all this preprocessor goodness was LiveReload (screencast). I'm still a fan. It now available on the App Store for $9.99. It is a menu bar app where clicking the icon in the menu bar opens a window of options.

LiveReload: the menu bar icon, the app window, and a browser with the browser extension installed.

You tell LiveReload to watch a particular folder. When any file in that folder changes, it triggers preprocessing. It can do a whole bunch of preprocessors. For CSS: LESS, SASS (w/ Compass), or Stylus. For JavaScript: CoffeeScript or IcedCoffeeScript. For HTML: HAML, Jade, Slim, or Eco.

After it's preprocessed, it reloads the page in whatever browser(s) you have the browser extensions installed in. If what you changed was just CSS, it injects the styles into the page without a page refresh. This is particularly useful where you are styling something on a page in a particular state. Let's say a click triggers open a dialog box and you're trying to style that dialog box. With LiveReload, you can leave that dialog box open and the newly injected styles will affect it, meaning not a lot of wasted time clicking and re-clicking.

But I've recently switched to CodeKit. CodeKit's UI is nicer, has more features (e.g. image optimization, JS concatenation) and less weird limitations (you choose whether or not file are preproccessed and where they go, unlike LiveReload where once you import it you can never get it to compile). The only thing I miss is LiveReload's ability to inject CSS without reloading the page, a handy feature for sites with complex states that require multiple steps to get the page back into that state after a reload. Update April 2012: CodeKit is now doing live injection of CSS.

There are a couple of things I don't like about LiveReload though. One is the screen where you tell it the output paths for the complied source:

I hate this screen

Notice the grayed out ones? It's trying to be smart and notice that you've included that file elsewhere. Thus it won't compile. But what if you want to compile it for some other reason? Too bad, no way to do it. It's just not a great UI and it can be a bit tricky to get started using.

And thus enters CodeKit. CodeKit has a beautiful UI.

Mmmmm. UI lovelies.

It's very easy to change the file paths to where files compile to. And I've never had to teach it, it seems to pick up on the directory structure and get it right from the get go. It will gray out files that are included too, but you can easily turn that on and off.

CodeKit is limited to LESS, SASS, Stylus, CoffeeScript, and HAML. I've found this to be a little limiting, as I've used Jade to preprocess HTML on a few projects. Jade is capable of HTML includes, which can be tremendously useful.

The error reporting on CodeKit is very nice. It's clear what's going on and it feels good when you resolve it.

Contrast that to LiveReload in which a little window slides down from the upper right of your screen with badly clipped text and no close button, and simply slides away once you've resolved it.

CodeKit also is unable to do the style injection that LiveReload can. This is how the creator feels about that:

Update: CodeKit does do live injection now.

Ultimately I think CodeKit is my favorite right now. What sets it above is all the additional features. It can automatically bless CSS. It can concatenate and minify JavaScript. It can tell you what files import any other particular file. And perhaps my favorite: it can one-click optimize images.


Another possible hold up to getting on preprocessors: working on a team. Specifically a team where multiple people are in and out of the same CSS files you are. If that's the case, all those people need to be set up with whatever preprocessing app you are using (you could use different ones, that's fine. Best if they are all running same core versions of the preprocessor). You can't have some people editing the .css files and other folks editing the .scss files. Those changes to the .css files are just going to get overwritten the next time someone compiles and commits. Preprocessors are unforgiving that way. They don't say "hey looks like there is some different stuff in this .css file from when I last complied it, want to take a look first?" Nope, they just write over it.

It's doable though. In a short period of time, we moved all of Wufoo to SASS. Actually, we moved a bunch of it to LESS, then some of it to Stylus, then all of it to SASS. Oof da. Credit there to Kevin. We also have all new development on SurveyMonkey using a big set of design patterns that are all using SASS.

If anyone has any team strategies for preprocessors, that would be valuable to share!


There are folks out there I'm sure that are upset at me for not using Compass. I know, I know. I should be. But obviously I'm slow on this stuff. I like understanding things as deeply as I can before proceeding and Compass is still a little fancy pants for me. If anyone has no idea what Compass is, it's a big 'ol set of add-ons for SASS. It means, essentially, that you don't have to write stuff that you'd likely have to write the same way project after project. CSS3 mixins, grid helpers, sprite helpers, file path helpers, and tons more.

My problem is that I'm not ready to relinquish all that stuff yet. I want to write my own. I'm sure the day will come when I give that up, but it hasn't come yet.

Little things that have tripped me up

This article started out with that title before ballooning into all this. But what the hey, I figure I'll still include these little tidbits that caused me a few moments of grief while learning.

Since I write my own CSS3 mixins, I might have a mixin for box-shadow like this:

@mixin drop-shadow ($x: 1px, $y: 1px, $blur: 2px, $spread: 0, $alpha: 0.25) {
  -webkit-box-shadow: $x $y $blur $spread rgba(0, 0, 0, $alpha);
  -moz-box-shadow:    $x $y $blur $spread rgba(0, 0, 0, $alpha);
  box-shadow:         $x $y $blur $spread rgba(0, 0, 0, $alpha);

It's full of sensible defaults, so the most standard usage can just be:

.module {
  @include drop-shadow();

Or if I want to get more specific, I can specify each part:

.module {
  @include drop-shadow(5px, 5px, 2px, -2px, 0.5);

But what if I want to do multiple box shadows? This mixin isn't ready for that. For those, I also prepare super generic mixins that are the spec name:

@mixin box-shadow ($string) {
  -webkit-box-shadow: $string;
  -moz-box-shadow:    $string;
  box-shadow:         $string;

This one only takes a single param, anything I want to give it. So the usage could be:

/* Bad! doesn't work! */
.stack {
   @include box-shadow(
        1px 1px   0 rgba(0,   0,   0,   0.100),
        3px 3px   0 rgba(255, 255, 255, 1.0),
        4px 4px   0 rgba(0,   0,   0,   0.125)

But that doesn't work. All those commas in there will confuse SASS. It will think you're trying to pass multiple parameters to a mixin that is only set up to accept one. You can't just put quotes around the value you are trying to pass either, that doesn't work. The answer is to use the double-parens technique:

@include box-shadow(( whatever, you, want, just, one, param ));

Another thing that screwed me up was trying to use variables within values, where the variable was only a part of the value. At it's most basic, variable are super easy:

$red: #F00;

.red {
   color: $red;

But I was trying to do:

$path: "/images/";

body {             /* Bad! No! */
   background: url($path/texture.jpg);

In order to make that work, you gotta use the hash/brackets thing:

$path: "/images/";

body {
   background: url(#{$path}/texture.jpg);

And one last little thing that might be confusing. The & character has special meaning while doing nesting. It equals the selector up until that point. For instance:

a {
  color: red;
  &:hover {
    color: pink;

turns to:

a { 
  color: red;
a:hover {
  color: pink;

You've probably seen example like this before. It doesn't quite sell it to do simple examples like this, but believe it or not, nesting feels natural very quickly and you'll love it.

But back to that & character.

You don't need to do this:

.module {
   & h3 {
   & p { 

That's just implied because of the nesting, you don't need to use the & there. You only need it when it's not going to be a descendant selector (space). Things can get extra sexy when you use the & later in the selector. Like if you use Modernizr to detect for multiple backgrounds:

body {
   .multiplebgs & {
   .no-multiplebgs & {

That gives you a really clean fork in how you want to handle the situation of support and non-support, all while keeping the code logically nested within the body { } statement.

That Dang FTP Workflow

Even if I've convinced to you work locally, get on version control, and use preprocessors, there is still that lingering issue of deployment. Your workflow might actually take a step backwards in efficiency if you came from live editing to now working locally, and when you want to go live you gotta manually upload changed files to the server. I'm afraid I don't have a great answer for you.

Nettuts covered it with "The Perfect Workflow," but that relies on a GitHub post-commit hook hitting a PHP file that `git pull`s which doesn't work on any server I have access to and is rare for a shared host to even allow that as I understand it.

This is where app-based cloud hosting really shines. Apps like Heroku for Ruby or PHPFog for PHP work into your Git-based version control workflow flawlessly. You can have it so you have one command for pushing to the repository and another for deploying live, or have it so when you push to the repository it automatically goes live.

Those cloud hosts don't work for everyone though. Back when I did agency work, the vast majority on it was just sites on some generic shared hosting. You could always install Git on those servers, then after you push stuff up to your repository, SSH into the server and git pull from there. That's better but still kinda janky and requires command line usage.

Ideally, apps like Git Tower could manage your Git Repos and also handle FTP, uploading files on command that it knows are out of date.

For those stuck on FTP4 workflows who aren't afraid of command line stuff, this looks promising.

The Other CSS Preprocessors

As I've made clear, I've chosen SASS for now as my CSS preprocessor of choice. But what about LESS and Stylus?

LESS was the first one I tried and honestly I still like it. I quite like how all the classes you write are automatically re-useable as mixins. Like:

.screen-reader-text {
   position: absolute;
   top: -9999px;
   left: -9999px;
label {

That's darn useful and more succinct than SASS would be. But I've been told that mixing classes and the concept of mixins together is fundamentally flawed. I'm not sure how, but there you have it. If someone wants to explain that I'd be anxious to hear.

One major turnoff I had with LESS was when I was getting errors just by using the standard @keyframe animation syntax. So ultimately I had to break that stuff off into another file, but those files had to be .css so as to not trigger the error, then I also couldn't @import them (literally include contents) because of the file extension. Maybe they've fixed that, not sure.

Stylus is nice too, largely because of it's flexibility. It's not going to bitch at you nearly as much as the others. Things like braces and semicolons are optional, not required one way or the other. While Stylus is nice and powerful and robust, I ultimately think the development behind it isn't strong enough to instill confidence in me. It's largely one dude (TJ Holowaychuk).

SASS ultimately won out because it's the most mature, easiest to find information and help about, seems to have the most active and robust development, and has the least bugs.

Tutorials Around Here and Final Words

Just for the record, I'm not going to start putting SASS in basic CSS tutorials around here. CSS will very likely outlive SASS. And besides, I think understanding CSS is far more important than some specific preprocessor way of doing things. In fact, if a CSS newbie asked me if they should learn SASS as they are learning CSS, I'd probably say no. Learn how CSS works and then later see how preprocessors can help you. That's the opposite of how I feel about JavaScript and jQuery, where I feel learning jQuery first is fine. Weird.

Essentially I think you should know what writing really good CSS is like. What that final CSS file looks like. The very file that the browser reads and processes to style websites. Then use a preprocessor to make that final, fabulous CSS file easier to write and maintain.

1 Yeah, it has Subversion built in, but it feels a bit tacked on. If you're into Subversion (and that's fine, it's easy) I think you're better off with Versions.

2 Except for little things like this or at work where I need to start up local servers running Python and stuff like that. But even then, begrudgingly.

3 At Wufoo, we moved from combining and minifying scripts on the fly with PHP to combining and minifying through preprocessors, which alleviated server load and made for even more efficiently compressed CSS.

4 Obviously by FTP I mean SFTP.


  1. Permalink to comment#

    I’m fairly new to SASS and LiveReload, but so far my only complaint is that I can’t really get the processed CSS laid out the way that I like it. I’m a little OCD when it comes to tab structure and layout of CSS and the final product isn’t really what I’m looking for.

  2. Rafał Krupiński
    Permalink to comment#

    “Point being: Write your sass/less so that the output is exactly how you would have written your CSS without it.”

    CSS preprocessors surely help making css more maintainable. The main reason for that isnt’t the awesomeness of the output they produce, but tools (mixins, variables) they offer. Dealing with a large project and being unable to use LESS/SASS features I’d rather try to achieve similar effect using other techniques (like oocss) which would eventually make the output look different. The point I’m trying to make is that writing your css the way LESS/SASS would, doesn’t make it any better.

  3. Great article. I’m just starting out with preprocessing CSS, so nice to hear your experiences.

    When you’ve been coding CSS the standard way for so long, it’s difficult to make a change. This has encouraged me though – to hear you are more productive.

  4. Permalink to comment#

    And for the FTP point – if you’re still using FTP for live site deployment in 21st century, you might be doing it wrong.

    • Cipa
      Permalink to comment#

      How so? I personally can’t do without working on the ftp. I tried almost everything. How would you make changes to a CMS website in terms of php code, js code and css code. What is your work process?

      I’m looking for a solution that allows me to work from multiple location on the same ftp-ed project. Any ideas?


    • If you have shell access to a server, you can do this:

      1) Throw your website up on Github so that any computer has access to it.
      2) Set your websites folder (which is a git repo git init) to point to the same remote repo that you develop with locally.
      3) Push changes from your local machine, or anywhere else which has a clone of the repository, up to the remote Github repo.
      4) Pull those changes down on your server with git pull.


    • Jason
      Permalink to comment#

      Please explain some constructive alternatives. I have so many cleints that are on shared (only ftp) servers… I don’t see any other way. Even if they had SFTP they wouldn’t still let me install git. The main thing which keeps me holding back on some projects are as well, easy deployment.

      Really great article Chris. Thank you for your point of view. Great to see Paul Irish here as well. Keep reading his work to Chrome Dev tools as well, absolutely quality stuff guys, thanks.

    • Permalink to comment#

      I agree with Jason
      Small clients don’t have git on their server or the host doesn’t support it. Unless you get a client who has its own dedicated server it’s hard to find a way to not code on the ftp.

    • I suggest looking into We use it for most web site projects. It’s basically a hosted git/svn service similar to Github but with automatic deployments via S/FTP.

  5. Permalink to comment#

    I’ve been using Sass for a while now, after writing CSS for many years and I have to say that I agree with almost every point. I can’t talk about the little app tools since I do like the command line. The most important part is that developers first have to understand CSS and then deeply understand what the pre-processors do and how they do it.

  6. Steve
    Permalink to comment#

    Anyone know any decent apps for PC? I’m not a Mac guy.

  7. Pete B
    Permalink to comment#

    Did you ever try CSS Crush? It has a slightly different take on preprocessing, PHP only though.

    • Permalink to comment#

      I was going to ask the same thing. I’ve been following the project but haven’t tried it yet.

      Their approach really intrigues me. You write native CSS files, which is cool, and the developer really tries to keep his syntax close to official proposals where applicable (i.e. the :any pseudo). I think it’s a great middle ground between pure CSS and LESS/SASS. If you’re learning CSS or bringing on a new team member, the CSS doesn’t look as alien while still providing many of the benefits of a preprocessor.

      I also like that it’s PHP based and combines, processes, and caches server-side on the fly.

      That said, what’s kept me from jumping in is the 1 or 2 things I’d really like to have in a preprocessor that are missing due to its “purity of syntax” approach. I can live without mixins (although I guess aliases can essentially so the same thing), but I’d really like nested selectors, first and foremost (:any doesn’t quite seem to provide the same advantages).

      Regardless, this is probably the one I’ll try first at some point.

      What’s your take on it?

  8. frances
    Permalink to comment#

    I keep hearing about SASS and LESS but have managed to avoid them for my clunky BBEdit approach, though I’m slightly curious to give preprocessing a try on a current project.

    For one reason, it’s unlikely to be SASS. I find their logo of ‘hot secretary on the phone’, and the tagline, ‘style with attitude’ boringly sexist and off-putting. It’s a small thing, just a logo and tagline, but it was the first thing I saw, but there’s way too much sexism in tech as it is.

    On a completely different topic, if you’re on a mac, it’s not much of a stretch to ditch MAMP. OSX already has Apache installed, installing MySQL can be done with a package and Sequel Pro is a fine replacement for phpMyAdmin – even upgrading PHP is not too traumatic, and for those who don’t want command line, VirtualHostX or similar makes setting up multiple domains embarrassingly easy.

    • tommy
      Permalink to comment#

      lol, have you ever read a tiny, 3 paragraph comment on the internet and instantly realized that you could go your entire life without meeting that person in real life. if you’ll pass up a possibly great product/service/tool because you don’t like the logo, I’m willing to bet that you’re not very fun to be around in real life.

    • T.Cretin
      Permalink to comment#

      @tommy, you ever read those one paragraph comments which have nothing constructive to add to the conversation, only to bash someone else who actually has an opinion? It’s a waste of precious electrons.

  9. Permalink to comment#

    I am also just starting out with SASS, great article.

    Would be cool if someone did a tutorial just on getting a workstation equipped and how to do your first file. I’m a bit overwhelmed with learning some ruby, some git, command line, all at once.

    Unfortunately I’m on a windows environment for work. CodeKit looks awesome, I’m using Aptana though.

  10. Ramkumar
    Permalink to comment#

    There is any option Without Rudy OR Python????

  11. Really?
    Permalink to comment#

    If you raise your eyebrows and offer sanctimonious comments at the prospect of someone using FTP to edit a site in the 21st century, perhaps you are being a ‘person’ wrong? Don’t be that guy.

    Expand, elucidate and educate please! That sounds like an interesting point/technique, someone may not have heard about it yet?

    […just like you hadn’t heard about it… until you read it somewhere or some generous soul explained it to you? ]

  12. stephband
    Permalink to comment#

    For those considering preprocessing: check out the DevTools Autosave plugin for Chrome, which automatically writes CSS back to your files as you edit it in Web Inspector. It’s a very fast way to work.

    You can’t do this sort of thing with a preprocessor abstraction layer in the way.

  13. Permalink to comment#

    I’ve always wanted to use a CSS framework but was scared thinking it might get me confused with the recently learnt jQuery syntax. Cris, your posts always compel me to learn something new. I learnt jQuery from your screencasts only :)

  14. Jacob Rask
    Permalink to comment#

    You should have an uber nerd write a Makefile for your projects.

    Our front-end developers just type “make static” or “make static-auto” in a terminal (it’s not scary, I promise) to compile all CSS and JavaScript. The auto option starts a watcher that compiles as soon as a file has been changed.

    You don’t need to (and probably shouldn’t) keep your CSS files in your repository, you just run the command to compile and minify the code either before or after you put in on the server. It could be as easy as a “make static-minified” command.

  15. ape
    Permalink to comment#

    @Chris Coyier – regarding team strategies

    I made the switch to SASS some days ago, and I’m really impressed – I like it. As I am somewhat a workflow perfectionist and catious when introducing new layers of complexity, I investigated possible workflow bummers and some other things the weeks and months before.

    Especially what to consider when using features like @include and @extend regarding a certain expected output after the compile step.

    e.g. @extend made me aware of the problem you already mentioned. As long as you are woking locally only everything is easy. If you’ re working in a (frontend) team, not necessarily on the same .scss files but on different modules etc. but only one development-server, you’ll get a problem.

    Every time one developer uploads his compiled .css the changes of the other guys get overwritten. Version Control won’t help in that matter.

    In order to get the best of both worlds, a) the independency of single .css files per module while working in a team – and b) the better maintainability (e.g. variables, used as constants for colours, fonts etc.) and all the other stuff offered by SASS, we decided the only comfortable and most promissing solution would be to have ruby + a watchfolder setup not only locally but also on the development-server.

    Instead of uploading compiled .css files, we just upload our .scss files and the compile happens serverside now. So every developer can see his changes and dosesn’t interfere with changes / updates of the others.

    Maybe that workflow is obvious for most, but maybe it helps some of you.

  16. I’ve been using SASS in a production environment for about 4 months and I’ve found it to be an incredible timesaver. It’s also pushed me to learn more about OOCSS and SMACSS and makes me want to write all around better CSS. Mixins are indispensable.

    Nearly all of the “Little things that have tripped you up” have been solved by Compass. I highly recommend you dig through the docs and start plugging away. Chris’s solutions to many of the css3 Mixins, browser fixes (inline-block, floats) are clever and useful and I find myself relying on them. Give it a shot!

  17. The team-workflow problem has been an issue for me moving forward with SASS. I like what is can do though.

    Generally I don’t favor preprocessors, especially haml & coffeeScript because they hide the language so much. But SASS does feel a little different since you’re only extending the functionality in CSS.

    I’m always weary about “stuff that produces the stuff you want” (code generation) because in the past, they’ve always come to be bad things and you’re at the mercy of a script to write your code for you. Seems almost Dreamweaver-esk in a way.

  18. Permalink to comment#

    Hi there!
    Well, I agree that using preprocessors *can* be a big timesaver, as well as mixins and the like have their moments, BUT their far from being production ready on a large scale.

    First, as soon as they have emerged, the scene has already become fragmented:
    SASS, LESS, Stylus, COMPASS, WTF?!, just to name the most prominent…
    (CSS has become successful because it is one standard everybody agreed upon.)

    And here is how they all will fail in a production environment:
    In every project, there will always come the moment where some hotfix has to be done, and to be done *now*, and the responsible developer will not be reachable, so somebody else will hack a little code directly into the css because that is the file he saw when inspecting the code…
    unless there is full documentation about how to submit your fixes (and the person knows about this docu in time).

    When there will be a regular touchup these hotfixes might be overwritten by the compiled SASS files etc etc.

    Well, which leads me to the point of using preprocessors in teams.
    Everyone involved has to be committed upon using that particular technology and has to know how to use it to its full extent. Have you ever tried to do that in a distributed team? No? Ok, have fun.

    In distributed teams the situation described above is far more likely to happen, as I can tell.

    For myself I cope with the situation by using zen coding [] and by still submitting normal CSS files.

    Towards Perfection,

    • Permalink to comment#

      This whole argument is based on false assumptions. Sass and LESS are not just “production ready on a large scale”, they are “already in production on a large scale”. Look at the list of sites/companies using Sass with Compass on the Compass home page for a small sample There’s also a little service called Twitter that uses LESS

  19. Have you considered/played with at all? It’s by no means perfect, but I think it hits a lot of your favorite features of these other tools (and possibly some others not mentioned)…

    – it’s browser-based (IE8+, Chrome, FF)
    – includes hosting if you want it (backed by Google Cloud Storage)
    – you get a live-preview pane that does style injection as you change your stylesheet (just like LiveReload)
    – provides a syntax highlighting editor with auto-complete
    – SASS support (with Compass if you care to use it)
    – automatic minification of your generated CSS (and ability to export pretty-printed CSS as well)
    – one-click deployment
    – easy to use in your local development environment

    It’s biggest shortcoming when compared to these other tools is probably version control. Right now, WebPutty only handles a preview version that you can mess around and try new ideas in, and the published version that is actively being served to your website(s). The good news is that there are plans to add more robust versioning and version control integration in the future.

    Full discolsure: I’m one of the developers that wrote WebPutty :)

    • Klaus
      Permalink to comment#

      +1 for WebPutty. I’m using it just for SASS, now I’ll start digging Compass/Blueprint – I want to upgrade old code written for

  20. Great article. For anyone trying to decide whether the overhead of a CSS preprocessor is worth it, I would just add the possibly obvious point that the benefits are directly proportional to the complexity of the CSS you’re writing. If you’re using a lot of CSS3 and working on large sites or multi-site architectures with multiple layers of inheritance, the advantages of a preprocessor are quickly realized.

    If you’re a one-person shop working with simpler site structures, your “This is unnecessary” instinct may be right. But of course being curious and learning about new technologies is always a good idea, so you should experiment with this stuff anyway. :)

  21. Permalink to comment#

    I hate maintaining parallel versions of local and live sites. I always start out local for the speed advantages, but once the client needs to see something, I upload it to the server where the site stays live– I don’t touch the local copy after that.

    I used .LESS on every project (and have for about 6 months) and will continue to do so. (Although your article has piqued my interest in SASS). I started out using the .LESS pre-processing app for Mac which was very convenient while working locally but ruined my workflow when going live: having to edit a local .LESS file, then upload the outputted local .CSS file every time to make changes to a live site is absurd.

    What saved my workflow is LessPHP (see and It is still in development, but the only real errors I’ve found have to do with processing calculated percentages which is not so hard to work around. Just adding a couple lines in my header.php file automatically checks for a new version of the .LESS file and, if so, outputs the CSS file when the page loads. No need for pre’processing apps or editing or uploading CSS files.

    I’m not sure if there are any significant speed/performance concerns with using a PHP based pre-processor but would be interested to know if anyone knows anything about this.

    • Gerald
      Permalink to comment#

      Definitely with leafo integrated into some php framework is a huge gain of time! Last optimisation is the use of dresscss or bearcss to build the lessed skeleton from a html file. It implies that you build your markup first then use the tool. One way among others…

  22. Spencer Mize
    Permalink to comment#

    We do our development locally (with the help of GitHub). We use Capistrano to pull from GitHub to the development machine, and then use Capistrano again to deploy to the live server. We’ve rigged it to share common files (icons, images) across all development installations.

    I’ve been using a custom PHP preprocessor, but with community support for SASS etc. growing, it sounds like that’s my next avenue of process improvement!

  23. I’ve used Coda for years and tried to comprehend SASS, but the Ruby gem thing and command line stuff threw me off. Bryan Jones’ turned out to be a perfect fit. Now I’m using his latest, CodeKit–and am extremely pleased. And I agree with you, Chris–the image optimization is sweet.

    Another point worth noting is that some powerful rapid prototyping frameworks utilized preprocessing: Twitter Bootstrap (LESS), Foundation has a LESS fork on GitHub, and Perkins (LESS).

  24. Moving to LESS+LiveReload has been fantastic for me. It would feel backwards to not use them now. For those just thinking about wading into the waters, just do it. SASS has a bit of overhead associated, but you can get LESS up and running in a minute.

    For those wondering if/why they should use LESS: Have you ever re-written the same hex colour in a file? That’s reason enough right there.

  25. Right! For those still working via FTP off remote servers, you really should invest a day or so in learning Git and integrating Github into your workflow.

    I develop everything locally, commit a few changes, push to Github, and then pull to my live server. In fact, I’ve automated that pull—now, all I really need to do is make changes, commit and push.

    If you’re still using FTP and doing things on the live server, you’d be doing yourself a huge favour by learning just a tiny bit of Git.

  26. Permalink to comment#

    I enjoy the ability to use variables and mixins, and I do see the value of using systems like these in your workflow. However, you must be careful with how you let them impact your coding style, I’ve seen too many great designers begin nesting everything because they can, and you wind up with unnecessarily long selectors, extreme difficulty in overriding styles due to specificity issues, etc.

    It’s also less than enjoyable trying to convince your entire team to install the necessary sass syntax highlighting plugins for their favorite editors, and trying to make the developer tools of each browser properly identify the source css as the sass file, and not the generated css file.

    If you can begin a project in a way that avoids many of these complications, it’s a great way to use sass/less, etc.

  27. Art
    Permalink to comment#

    Thanks, Chris. Lots of good resources here.

    I’ve been setting up my own personal framework using SASS and Coda snippets, but now I’ll be checking out some of these tools as well.

    I noticed that CodeKit has an area to display installed frameworks and was wondering if you knew whether creating custom frameworks was possible as well?

    Also, one-or-many mixins in SASS can be constructed based on the looseness of SASS lists. SASS lists can be either comma separated, or space separated, and you can have lists of lists so long as the separators are different.

    @mixin single-shadow( $x: 1px, $y: 1px, $blur: 2px, $spread: 0, $color: rgba(0, 0, 0, 0.25))
            -webkit-box-shadow: $x $y $blur $spread $color;
            -moz-box-shadow: $x $y $blur $spread $color;
            box-shadow: $x $y $blur $spread $color;
    @mixin box-shadow( $shadow1, $shadow2, $shadow3, $shadow4, $shadow5, $shadow6, $shadow7, $shadow8, $shadow9, $shadow10)
            @if $shadow2 {
                    $shadows: '';
                    @each $shadow in $shadow1, $shadow2, $shadow3, $shadow4, $shadw5, $shadow6, $shadow7, $shadow8, $shadow9, $shadow10 {
                            @if $shadow {
                                    @if $shadows {
                                            $shadows: #{$shadows}, #{$shadow};
                                    } @else {
                                            $shadows: $shadow;
                    -webkit-box-shadow: $shadows;
                    -moz-box-shadow: $shadows;
                    box-shadow: $shadows;
            } @else if $shadow1 {
                    $x: nth($shadow1, 1);
                    $y: nth($shadow1, 2);
                    $blur: nth($shadow1, 3);
                    $spread: nth($shadow1, 4);
                    $color: nth($shadow1, 5);
                   @include single-shadow($x, $y, $blur, $spread, $color);
            } @else {
                    @include single-shadow();

    Then all three should work (probably needs some tweaking as it was just off the top of my head):

    @include box-shadow( 
            1px 1px 0 rgba(0, 0, 0, 0.100),
             3px 3px 0 rgba(255, 255, 255, 1.0),
             4px 4px 0 rgba(0, 0, 0, 0.125)
    @include box-shadow( 
            1px 1px 0 rgba(0, 0, 0, 0.100)
    @include box-shadow();
  28. For deployment, I’ve been trying out Beanstalk ( It provides private Git (and subversion) repositories, and has a mechanism for pushing changes to the repository to a server. I have just the basic free account, so the deployment mechanism is somewhat limited, but I believe for the paid accounts you can deploy both to a staging server (automatically when the repository is updated) and then manually to a live server. It’s pretty sweet, and is easy to use (if you understand GIT, of course).

    • I second that, Dave. Beanstalk is by far the best way to go, in my experience, when you’re an agency and every client’s hosting setup is a bit different.

      It has the enormous benefit of standardizing the deployment process, so your whole team deploys through one point. And it can show you a report of everything involved in that deployment, such as what files changed, what tickets were closed, and what git/svn commits took place.

      I’ve tried a lot of other options, but that’s the winner.

    • Cipa
      Permalink to comment#

      How’s beanstalkapp compare to bitbucket?
      Bitbucked is free for private repositories.

    • @cipa It doesn’t look like Bitbucket has deployment — in other words it does provide free PRIVATE Git repositories (cool!), but they don’t have a mechanism to push those files to a web server for staging or live deployment. That’s what intrigues me about Beanstalk.

  29. Permalink to comment#

    For anyone looking into automated uploading sans-git, check out the command-line tool rsync

    It’s can do differential file transfers from local to remote (ssh)

  30. Permalink to comment#

    I’m at the stage where I develop WordPress themes locally and host them on a git repository ( just the theme, not the whole site), as a backup.
    you can get free private repositories at For public projects I prefer Github, but for client sites I use private repos at Assembla.

  31. I disagree with developing locally, the best method is to version your project and have multiple working copies on multiple subdomains.

  32. Ryan
    Permalink to comment#

    Coolness. I didn’t know about MAMP (so that’s what I found useful about this post). I love working locally – one of the sites I work on uses a rails server (and I code in HAML and CSS… not SASS yet, sorry). But I also work on a lot of WordPress sites, and haven’t even bothered to look at the local options.

  33. Permalink to comment#

    @Scott Vivian, @Methemer: if you add () behind the mixin Less will not output the css

    .screen-reader-text () {
      position: absolute;
      top: -9999px;
      left: -9999px;
    label {
      position: absolute;
      top: -9999px;
      left: -9999px;
  34. I have been loving Sass and Less. Actually reading the documentation has helped in a huge way. For instances, Sass has a mix() method that lets you mix two colors with a weight. Why?

    // create a basic two-stop gradient mixin
    @mixin gradient($gradstart,$gradstop,$stop1,$stop2) {
      background: mix($gradstart, $gradstop, $stop1);
                    // mix(color1, with_color2, weighted_percentage)
      background: -moz-linear-gradient(top, $gradstart $stop1, $gradstop $stop2);
      background: -webkit-linear-gradient(top, $gradstart $stop1,$gradstop $stop2);
      background: linear-gradient(top, $gradstart $stop1,$gradstop $stop2);
                    //et cetra...
    .button {
      // call your mixin
      @include gradient(#f6ffb4,#526b08,40%,100%);
      // mix() can create a really good single-color fallback that mixes the gradient colors by their visual average!
  35. Very interesting. As a noob, the idea of fully learning CSS first and then preprocessors later, really resonated with me. thanks!

  36. Permalink to comment#

    It surprises me that no one mention that SASS actually have 2 different possible syntax.


    a {
      @include gradient(...)
      color: red;
      &:hover {
        color: pink;


      color: red
        color: pink

    I personally prefer .sass

    • Ray
      Permalink to comment#

      I prefer the .sass syntax, too. No curly braces and semicolons everywhere = less typing, more readable, more fun IMO. Then again, I’m an old Pythonista ;)

      Many people are not comfortable with the whole indentation-based thingy, though, or feel it strays too far from what plain CSS looks like. The good news is, both syntaxes are interchangeable, i.e. you can import .sass into .scss (and vice-versa) and it’ll compile without conflict. SASS even comes with a command line tool to convert source files between the two flavours, should your tastes change.

  37. Permalink to comment#

    If you want to reload CSS into a live page without the other tool, it’s pretty easy to do so in javascript. I have the following in my javascript and call it as needed (you could put it on a timer or I’ve seen a bookmarklet to do it too). This uses Ext to find the DOM nodes and I force a different URL so my webserver can cache the file but this bypasses it, and it’s using underscore.js to iterate the loop but it’s pretty simple stuff

    reloadCSS = function() {
      // force reloading CSS by finding linked sheets and adding/changing a query param
      _.each(Ext.getDoc().query("link[rel=stylesheet]"), function(link) {
        if ((link.href || "").match(/^([^?]+)\??(.*)$/)) {
          link.href = RegExp.$1+"?"+Ext.urlEncode( Ext.apply(Ext.urlDecode(RegExp.$2),
                                                                         { forceReload: Math.random() ) }) );

    And yeah, make gives you an easy way to script “recompile everything that’s changed and put it somewhere” – personally I transfer files to my dev server by simply having the dev server mount my working folder so I can test without having to commit changes to source code control etc, and I use emacs so it’s pretty simple to get emacs to always recompile SASS files whenever you save them… but that’s what happens when you get old skool C++ developers working on your web projects :)

  38. Permalink to comment#

    Chris: Wonderful, informative right-up. Does using a service like address the issues you had with FTP Workflow? That’s pretty much my M.O. now, working solo or with my team.


  39. If you are a SCSS user you have to check out Bourbon.

    From Site:

    “The purpose of Bourbon Sass Mixins is to provide a comprehensive library of sass mixins that are designed to be as vanilla as possible, meaning they should not deter from the original CSS syntax. The mixins contain vendor specific prefixes for all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties. Bourbon uses SCSS syntax.”

  40. Nate Atkinson
    Permalink to comment#

    Coda has a great built-in FTP, so that solves your FTP dilemma. Also, I really enjoy Cornerstone for SVN

  41. For LESS, there is an alternative application for multi platform, SimpleLESS ( the interface looks like LiveReload ). SimpleLESS

  42. Collin Garvey
    Permalink to comment#

    Nice write up.

    Gonna be honest though, not really digging the command-line hate. It’s really not scary and IMO, Designers & Front End Devs shouldn’t be discouraged from using it. A lot of what we do as Front End Devs on a daily basis is way more complicated.

    I guess I don’t understand how someone can cope with JS, CoffeeScript + jQuery, box model, version control and browser quirks, but then hate using the command line. At the end of the day it’s just typing the right things in to a text box to accomplish what you’re trying to do.

    I’m still learning a lot of what the command line has to offer, but everything I’ve learned so far as served to make my life easier on a daily basis. GUIs make a lot of things easier, but in their “simplification” they can sometimes obscure or omit some really cool command-line features (See: GitHub App).

    It kinda just kills me seeing so many really smart people disregard or write off the command line as lame/frustrating/complicated when it’s obvious they just haven’t been shown some cool things it can do or haven’t taken the time to sit down and learn.

    • Kenneth White
      Permalink to comment#

      I can speak to that as a former designer turned developer who is just getting into command line. For me it boiled down to the worry that command line is a direct tap into my computer, and unlike the operating system and its friendly UI, command line operations aren’t safe from me—the worst part of the computing cycle. The sentiments I hear from fellow designers are similar, “I don’t want to accidentally destroy my computer.”

      I think it’s getting better and you nailed it on the head. Designers and front-end devs just have to be shown that it’s all gonna be okay.

    Permalink to comment#

    Hey Chris,

    Great article, I’m a big fan! Thought I would share my two cents on how we use pre-processors as a team at

    We have a main Ruby on Rails project where we use Sass, Haml, and Coffeescript. We started the project pre 3.1’s asset pipeline so we use a set gems to compile these files on page reload.

    To avoid the issues you mention about the confusion of other members wanting to write to the compiled assets we take the dictatorship position and write to our .gitignore file to ignore all javascripts/css files except those inside “vendor” folders. So even if someone wants to write to the compiled assets it won’t be put in version control.

    Finally Jammit packages/minfies/gzips everything for speedy production use.

    This is all very Ruby & Rails specific, but we also have some projects built on node.js and for that I wrote a little module.

    This has worked out wonderfully for us so far, and overall has made our team much more productive.

    I find the extra boilerplate work of setting up a system to seamlessly compile pre-processors worth it, especially for big projects. We spend a lot of time experimenting with different UIs and writing a lot of js/html/css so it makes life a lot more pleasant to have robust feature-rich tools like these.


  44. git-ftp (the this in “this looks promising” under That Dang FTP Workflow) is awesome.

    if you use git (from the command line) and can’t use it on a project because of the server, check it out.

  45. Permalink to comment#

    Maybe also give our a try? :)

  46. Permalink to comment#

    I’m really bad in css but this blog always help me out ;)

  47. Regarding the (S)FTP-Git-Deployment-Problem: I used dandelion ( for some smaller projects and it works like a charm. And after creating a simple config file it only requires one line of command line use: dandelion deploy – that’s something every designer can handle ;-)

  48. Permalink to comment#

    Thanks for the extensive article. I feel like I have been living in a hole because this is my first read on SASS. Now for more research…

  49. @extend is able to function more like your Less example as of Sass 3.2 (gem install sass --pre) with placeholder selectors.
    I’ve already converted all of my reusable classes over to a _placeholders.scss stylesheet.

  50. I have a little input for about FTP deployment and SVN. A client I work with has a traditional application development environment with 3 zones:

    – Development (localhost.?????)
    – Staging (stage.?????.com)
    – Live (www.?????.com)

    I’ve been using Beanstalk for deployment for the past 6 months ( and it’s amazing. If you haven’t seen, heard, or used it: Beanstalk allows you to easily create “deployment” zones in their app using FTP/SFTP details.(

    I have automatic deployment setup on the staging environment, so when I commit a group of changes they are automatically FTP’d to stage.?????.com. When we have everything working on staging I typically login to Beanstalk and hit the deploy button to push everything over to live (even if it’s a series of multiple commit’s).

    I also have the option to commit to a specific environment by adding “[deploy:environment]” to the end of a commit message. I use this all the time to quickly make a change on the Live site with [deploy:Live].

    The client has an account in Beanstalk, and is automatically notified of new deployments. I’ve found that this works well for clients that are typically more technical.

    The only downsides I’ve found is that an SVN remove and delete command will not remove the files via FTP. With a more advanced branching setup this can be done, Beanstalk will remove files and directories from your server that no longer exist in the deployed branch.

    As a disclaimer, I have no affiliation or connection with Beanstalk. This info is solely based on my experiences working with it.

  51. Hey Chris, thanks for the writeup. I’ve been toying with the idea of using a preprocessor for CSS, but was (and still am) hesitant for many of the same reasons you mentioned. I’m very interested in the perks to using them (most notable – less typing)

    It’s good to see that you’ve found yourself more productive using SASS that not using it. I think that is the most important testament. Thanks also for talking about the workflow, that is the main reason for my hesitation. It’s a matter of choosing to use it and also making it the SOP for the team.

    Also, on the ftp note. I usually locally edit files and then upload via ftp to a live beta server where I preview my changes. I do this because I work anywhere and so do not want to be bound to one workstation. All the while using version control.

    I’m mostly interested if there is something like phpless or lessjs, that will live server side and then compile the css on upload. Then I don’t have to futz with saving files and then finding the updated one to upload to server. This would remove the css file from my workflow completely, I’d only be concerned with the actual source files. Any hints on where to go (coming from soneone not familiar with node or command line)?

  52. Michael Ware
    Permalink to comment#

    Just tried LESS for the first time and ran into a few roadblocks with Chrome. Compiling errors would come and go, but the main drag was that Chrome’s web inspector stopped showing the file name and line number of css styles. Has anyone else run into this? Any solutions? or just try again?

  53. I’m here from the team at Beanstalk – I just wanted to say thank you to all of the loyal fans for mentioning us here. It really makes our team happy to know that people are finding us to be a better way to get their changes deployed. Just a few weeks ago we released a brand new version of our deployments engine and it’s even more badass than it was before. Team deployment notifications & automatic release notes are among my personal favorites.

    If anyone has questions about our deployment tools, please let me know here or drop me an email

  54. Permalink to comment#

    Why do I see the future of this site to be It’s been pretty awesome to watch you explore new technologies all these years and allow us to have front row seats.

    As a user of SASS and git for the past three years, it is awesome that you have added these powerful tools to your workflow as well.

  55. Jay
    Permalink to comment#

    One massive advantage of using LiveReload with it’s new script method is getting auto-refresh on iOS simulators (including soft-refresh of CSS). That is pretty much the best reason to use it.

  56. Permalink to comment#

    I’m not sure you do have to work locally. My workflow consists of LESS + lessphp, which dynamically recompiles, minifies and gzips my LESS files whenever I call the stylesheet (which is at as opposed to There is a little overhead with this processing, but when combined with caching the outputted CSS (if there are no changes to the LESS files) this is minimal.

    Works for me!

  57. Sam
    Permalink to comment#

    I really love th idea of using LESS / SASS however I use Beanstalk to store mymain repo while devloping if I compile through codekit and then push to the server my team wont be able to get the LESS/ SCSS files they will see the compiled code, is there a way to compile on deploy to the main servers using Beanstalk.

  58. I’ve only just started using SASS and my first impressions are pretty darn good, I love using mixins and @if’s are pretty cool, I am a one man band and don’t have a real need for a workflow that allows for multiple users to make changes to files however, because of reading this I can see the benefits and will start looking into setting up a proper workflow. As always amazing resource Chris thanks.

  59. @chriscoyier – Looks like Bryan added support for Jade a couple builds back – was getting frustrated with HAMLs lack of HTML includes myself –

  60. Just wanted to share my work strategy in light of this post. I use Codekit to process my SASS code while working on files locally located on my Dropbox. After CSS has been preprocessed which takes about a second, I use Transmit FTP to synchronize my theme (wordpress files) online.

    Working locally may be faster but I suppose it would depend on what you are working on. I prefer to always have accessibility on my files online and dropbox allows me to have a single location accessible on any computer. This allows me to use both PC for convenience and MAC for pre-processing my code.

  61. Hi guys, my preprocessors journey started with LESS. Very soon I continued with SASS. Everything was really cool but once I decided to write my own framework I spotted several problems. There was no a syntax in SASS which allows me to do what I wanted. I had some problems with the interpolation and at the end I decided to write my own CSS preprocessor. It’s called AbsurdJS I’m really interested to get some feedback. Here is something like “get started” article.

  62. Is it not difficult to work with the compiled files when you are debugging a website in your browser with Firebug? Will it show as normal CSS?

  63. If you on PHP devs you can use PHPStorm (mac | windows), have an automatic filter to generate .CSS from SASS & SCSS files.

    Not to hard to configure and you can easily work in one platform ;)

  64. Permalink to comment#

    If you use FTP, write PHP, and need a solution that doesn’t require syncing local files and live files, I highly recommend SCSSPHP. A couple extra files in your project folder and you’re serving compiled Sass. I understand that git deployment is where it’s at, and I do that for personal projects. I can’t change everyone at my company’s workflow; I can, however, slide in an option that allows us to write cleaner CSS without forcing people to learn a whole bunch of new things at once.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".