Preprocess THIS!

Now, let’s be clear, the point of this article is not to debate the benefits of one preprocessor over another. They each exude awesomeness in unique ways that fuel devoted fan bases. Sass is simply the best solution for me and my workflow. Thankfully, the dev team at Happy Cog agrees. We have since worked Sass into our starter files, using this change in our process to reinvent how we write the presentation layer as a whole.

Lingering Concerns

I noted two primary concerns with preprocessors—debugging and code bloat—in my previous post, and, to be honest, I’m still working toward the best solution for both issues.

Debugging

I wish there was a clean way to use line numbers generated in Chrome’s Web Inspector and/or Firefox’s Firebug to reference source stylesheets. When tightening up and debugging styles, I tend to lean heavily on Web Inspector to make updates on the fly, test in the browser, and copy edits to my stylesheet. Web Inspector is kind enough to reference which line in the stylesheet each style maps to. This is great if you are writing vanilla CSS but useless when writing with the aid of a preprocessor. Preprocessors (please allow me to state the obvious) process your shorthand, abstracted styles into a full CSS document for browsers to read. So, the line numbers in your source files just won’t match up. Thus, devs must use the text editor’s (sometimes-wonky) search function when flipping back and forth between browser and project to debug. Codekit has a debug setting that ~kind of~ works. It prints the source file and line number above the outputted style, however it’s a version-control conflict nightmare. I’ve found the generated reference line numbers to be inaccurate in many instances so I’ve turned them off. If you’ve solved this problem in your workflow, please, by all means, share with the rest of us wary searchers.

Code Bloat

My struggle with generated code bloat has been largely solved by simply keeping mixins (blocks of code that are defined once and can be reused) as short and efficient as possible. The basis of a solid design system, in my mind, is comprised of many small units of repeated design patterns used with purposeful deviations. To this point, I generally try to keep mixins as compact as possible, reflecting these small units of design patterns in three properties or less. I’ll then build on them in the declaration itself, if necessary. This keeps me from having to overwrite styles bundled into mixins in the very same declaration (gross). These solutions have worked fairly well for me, but I am still working to refine what happens when I begin to group selectors and bundle an @extend into the declaration (hint: it’s not pretty).

Sometimes Low Hanging Fruit Tastes the Sweetest

What is it about preprocessors that convinced me it’s okay to overlook these lingering issues? Well, there are tons of cool techniques you can integrate into your workflow with Sass, and more features and benefits are published with every new release. But, let it be known, it’s not the custom functions or control directives that have me hooked. To me, the greatest, most time-saving benefits still lie in the preprocessor fundamentals.

Nesting Rules

The ease of never having to repeat class names over and over again is a huge win for me. Hover, focus, and active states with the parent selector? A breeze. Simple wins, sure, but after going back to vanilla CSS for legacy projects, these features are greatly missed.

Variables

Variables are awesome for a variety of reasons. What I love most about them is they force consistency across the design system. These days, I’m rarely writing raw hex values into stylesheets, because most colors are defined as variables.

Mixins

With mixins, I never have to bother with the oh-so-cumbersome task of writing out vendor-prefixes for properties again. Gradients with CSS? Listen, I love navigating out to the Colorzilla Gradient Generator as much as the next guy, but can you honestly compare this:

 @include vert-gradient(#383838, #202020);

to this:

 background: #383838;
 background: -moz-linear-gradient(top, #383838 0%, #202020 100%);
 background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #383838), color-stop(100%, #202020));
 background: -webkit-linear-gradient(top, #383838 0%, #202020 100%);
 background: -o-linear-gradient(top, #383838 0%, #202020 100%);
 background: -ms-linear-gradient(top, #383838 0%, #202020 100%);
 background: linear-gradient(to bottom, #383838 0%, #202020 100%);

It’s not even a fair fight.

Better Collaboration

Lastly, any major shift in personal process will undoubtedly impact team members and likely the client too in some way, large or small, right? As far as internal communication goes, Sass variables have proven to be a much easier way to discuss styles with the design team. When I post for internal review, I post my variables as well. When the designer runs visual QA, they post (or sometimes update themselves) value changes to variables. Very efficient.

Externally, template handoffs to clients or their third-party CMS vendors have been very smooth. Using the SCSS syntax makes handing templates off for CMS implementation as easy as pie. Clients and third-party vendors don’t have to commit to a new syntax, and vanilla CSS will not cause conflicts. We also bundle a Codekit config into our final files so, should they choose to use the app, the project settings are already set up for them. We’ve even seen a few clients and third-party vendors fold Sass into their own development processes after experiencing the benefits in projects where we collaborated.

At the end of the day, I highly recommend you at least try incorporating a preprocessor into your presentation dev workflow. If you’re hesitant, I hear you. I was in your shoes, and my best advice is to forget about all the fancy features and functions and instead focus on the basics I outlined above: variables, mixins, and nesting rules. Watch this screencast by one of my longtime dev heroes, Chris Coyier or read this article from Chris Eppstein, creator of Compass and Sass core team member. Give yourself some time and I’m confident you’ll feel compelled to write your own “OH MY GOLLY I LOVE SASS” article in 10 months too.

Back to Top