A Response to “Preprocess THIS!”

So, I’ve already posted a bit about how CSS preprocessors (namely, Sass) can save you gobs of time when coding a responsive site. In the week since I posted that, I’ve discovered even more tips and tricks that make preprocessors an almost necessary part of your responsive development portfolio, and I’ll share those with you in the near future.

In the meantime, I wanted to respond to Allison Wagner’s post entitled “Preprocess THIS!”, and address some of the concerns she had regarding Sass and how we at RP3 Agency have begun to address the same issues.

Debugging

Let me add +1 to those who’ve already mentioned FireSass. If you turn on Sass debugging, this plugin for Firebug will point you to the line in your Sass code where the actual, “this is where you want to make the change” line is. Amazing!

Yes, this means you have to use Firefox (a bit passé in some circles, I know), but Firebug is the reason I develop mostly in Firefox. Hands down, I still much prefer it over the Webkit web inspector.

Version Control Conflicts

In Allison’s post this goes along with the debugging tool. But our solution at RP3 Agency has been to not submit any compiled Sass code to revision control. Instead, we’ve made compilation of Sass into CSS via Compass part of what our build scripts do, and only the source Sass files are committed to Subversion. This has the added benefit of being able to deploy CSS to test and staging environments with the Sass debugging turned on, and compressed, non-debugging CSS to production environments. This is a brand new process for us, but so far the results are very promising!

Hand-in-hand with this part of the process, our developers all use CodeKit to compile our Sass in development. (Sure, you can use Compass or sass --watch to achieve the same results, but we were looking for methods that don’t require the command line.) What this means is you never have to point your HTML files (or WordPress templates, or what have you) to a “development” version of your CSS while you’re working on it, and then switch it to a “production” (read: minified) version when you go to build to production. Your compiled CSS file is always living in the same place, with the same name, optimized for the environment its living on.

Code Bloat

In her post, Allison references some of the great work by Chris Coyier in getting the word about about Sass. He’s also mentioned in his podcast, Shoptalk Show as well as in an interview on SassCast that when you serve your CSS files compressed with gzip (you are doing that, aren’t you?), the repetitive patterns caused by CSS preprocessor nesting get squeezed into itty-bitty pieces, making the code bloat almost negligible and not really a problem at all.

Conclusion

I’m full on the CSS Preprocessor bandwagon, and while like a lot of people I started with LESS, Sass has now become my preprocessor of choice. As I discover new tricks and refine my processes, expect to read about them here.

Leave a Reply

Your email address will not be published. Required fields are marked *