Skip to main content

Cognition

Preprocess THIS!

Related topics:
Front-end Development
Preprocessors

A while ago I wrote a little post discussing my dive into CSS preprocessing, and, at the time, I wasn’t totally convinced that this hot newness was the best approach for my workflow. I shared my internal struggle with bloated output and questioned if this preprocessor business really did save me that much time. When I wrote the article, I had only worked with LESS, one of several popular CSS preprocessors, as it was a project requirement. Many of you fine folks suggested (both on Cognition and off) that I try Sass. Well, I did. Fast-forward 10 months and HOLY TOLEDO THIS FRONT-END DEV IS SERIOUSLY SASSY AND LOVING IT.

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

52 Responses

Tweet your thoughts

We will not now, or ever, tweet without your permission.

or

Respond on your Blog

What does this mean?

If you have more than 120 characters of thoughts, why not write a response on your own blog?

If you keep it professional and make a good point, we’ll post your first paragraph here. But if we can’t pull your post in for technical (or editorial) reasons, we still appreciate your feedback!

or

52 Tweets and 0 Blog Posts (also 60 retweets, not shown)

  1. @happycog

    After 10 months of use, @alliwagner writes for Cognition about the good and the bad of employing CSS preprocessors: http://t.co/hAZXLD4U #fb

    Thu, September 13, 2012 10:48:07

  2. @BBerkner

    Great article-> @alliwagner writes about the good and bad of employing CSS preprocessors: http://t.co/5I7tQqMh #fb (via @happycog)

    Thu, September 13, 2012 10:58:53

  3. @joesnellpdx

    Unsure about preprocessors? Great article from a pro dev's perspective - after 10 months in use.

    Thu, September 13, 2012 11:26:00

  4. @acolangelo

    .@alliwagner on the good and bad of CSS preprocessors. Awesome read for anyone interested, from beginners to experts. http://t.co/213aRHNS

    Thu, September 13, 2012 11:38:00

  5. @webbower

    Re: debugging, a former co-worker of mine liked https://t.co/pB8xl4L2 http://t.co/RrO6OVZN

    Thu, September 13, 2012 12:10:45

  6. @alliwagner

    It's been 10 months since I first started working with CSS Preprocessors and I've learned a few things along the way: http://t.co/dnRHEe1f

    Thu, September 13, 2012 1:13:20

  7. @spaceboyDFS

    HOLY TOLEDO THIS FRONT-END DEV IS SERIOUSLY SASSY AND LOVING IT. http://t.co/ly96wHQ3

    Thu, September 13, 2012 1:22:09

  8. @publishink

    Sound advice @alliwagner. Add @chriscoyier’s Don’t Over Think Grids http://t.co/RkUJfF6k http://t.co/xtFWLFfX

    Thu, September 13, 2012 1:45:14

  9. @lideebe

    Preprocess THIS! http://t.co/EQXDxwek

    Thu, September 13, 2012 2:02:13

  10. @RyBacorn

    http://t.co/wzhK06Qo clean up your css

    Thu, September 13, 2012 2:07:34

  11. @wanderer7790

    http://t.co/iRqD0btQ

    Thu, September 13, 2012 2:20:20

  12. @jaasum

    If you think Sass alone is amazing combine it with http://t.co/VzkYGQc7 and never look back. http://t.co/26kFRuLb

    Thu, September 13, 2012 2:27:18

  13. @happycog

    Our own @alliwagner atop http://t.co/RAH6Fqi7 How about them apples? Read her article on Cognition: http://t.co/hAZXLD4U

    Thu, September 13, 2012 2:37:51

  14. @stefanoortisi

    Preprocess THIS! http://t.co/cWIQKd5W #css #preprocessing #webdevelopment

    Thu, September 13, 2012 2:57:39

  15. @CWSpear

    Cool article. Look into compression to make bloat from CSS preprocessors negligible. http://t.co/HtcdpYiS

    Thu, September 13, 2012 3:06:33

  16. @anthonyshort

    You should use @extends and placeholder selectors to avoid code bloat from mixins. http://t.co/X7y25SBa

    Thu, September 13, 2012 3:47:09

  17. @duaneblake

    I use firesass - https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/, to debug my sass code in firebug

    Thu, September 13, 2012 4:03:09

  18. @amaxwell02

    I switched to Sass as well and the line #'s are a problem for me as well, I wrote this https://t.co/wfuJQcyO http://t.co/uNUWCpwD

    Thu, September 13, 2012 4:52:01

  19. @amaxwell02

    @alliwagner great article! Sass line #'s are a problem for me as well, I wrote this https://t.co/wfuJQcyO http://t.co/uNUWCpwD

    Thu, September 13, 2012 4:54:10

  20. @paul_irish

    @alliwagner we have experimental support for Sass line number mapping in Chrome DevTools http://t.co/BPjz1fxz http://t.co/PlYThsma

    Thu, September 13, 2012 4:55:10

  21. @tweetllama

    @alliwagner It's the nested media queries that allow DRY 'mobile first' CSS that's got me hooked on preprocessors. http://t.co/7SL2axGT

    Thu, September 13, 2012 9:09:31

  22. @bigskinnyboy

    Have you tried FirsSass or Sass Sleuth? Great debugging tools. http://t.co/or5I8gFh

    Thu, September 13, 2012 9:14:44

  23. @htmlcut

    Don't miss: Preprocess THIS! http://t.co/aM23H5RJ http://t.co/aM23H5RJ

    Fri, September 14, 2012 3:45:42

  24. @chuckneely

    read @alliwagner 's thoughts on CSS pre-processing. We use LESS over here @typecastapp -could never go back to vanilla! http://t.co/jXS5YIKU

    Fri, September 14, 2012 4:08:00

  25. @jayhan

    Ok, gonna try out Sass in future projects. http://t.co/4UAWNJ5M

    Fri, September 14, 2012 4:13:10

  26. @MarikendeRuiter

    Well, thanks Allison. I'm gonna try sass. http://t.co/PV0KX1eT

    Fri, September 14, 2012 9:13:30

  27. @mariqua

    CSS preprocessing > is it really the key to your workflow???? > http://t.co/GTU13GjD #html5 #css

    Fri, September 14, 2012 9:25:06

  28. @azzcatdesign

    EXACTLY!! Preprocessor variables & mixins FTW http://t.co/ufTNIZT6

    Fri, September 14, 2012 10:11:11

  29. @azzcatdesign

    You've hit the nail on the head. Mixins & variables=sweetness. Finding the line # is a challenge. http://t.co/ufTNIZT6

    Fri, September 14, 2012 10:13:56

  30. @alliwagner

    @jayhan @MarikendeRuiter @mariqua @azzcatdesign Happy to hear you're planning to give Sass a try :) Any q's lemme know http://t.co/dnRHEe1f

    Fri, September 14, 2012 12:19:53

  31. @fauverism

    Great article on SASS! http://t.co/i3GzeCSo

    Fri, September 14, 2012 12:29:10

  32. @dcmudie

    CSS preprocessing? @alliwagner may have convinced me to give it another chance. http://t.co/BuBhnSnm

    Sat, September 15, 2012 9:39:38

  33. @newchemical

    Good info and advice on css preprocessing - http://t.co/NnWvwu5F - I've been using LESS would like to try Sass

    Sat, September 15, 2012 12:58:52

  34. @abbakym

    as for debugging, JetBrains' WebStorm with CSS-X-Fire plugin works really well for me. http://t.co/p3JvjubH

    Mon, September 17, 2012 4:08:39

  35. @evo1

    For debugging, if you're using SASS you should be using FireSASS, makes firebug behave properly with the line numbers. http://t.co/ZjEz5TWw

    Tue, September 18, 2012 11:38:52

  36. @daxwhite

    A wee piece on preprocessing : http://t.co/05l7rNTM #CSS

    Tue, September 18, 2012 11:45:07

  37. @rouninmedia

    Reticent to try CSS preprocessing, but I've loved discovering PHP in 2012. Maybe SASS in 2013? @alliwagner talks CSSP: http://t.co/CCRVLpZv

    Tue, September 18, 2012 12:05:48

  38. @JasonNemec

    Ok, time to look into Sass. Great article -> http://t.co/hAZXLD4U

    Tue, September 18, 2012 12:12:37

  39. @GoosieM

    Good article on CSS pre-proc: Preprocess THIS! http://t.co/FuXdctHj

    Tue, September 18, 2012 3:07:58

  40. @japellerano

    Awesome article about CSS preprocessors titled: Preprocess THIS! by @alliwagner http://t.co/rs72bSWb

    Wed, September 19, 2012 4:21:03

  41. @Chardot

    Great article about CSS preprocessing. http://t.co/OtvcOKAD

    Thu, September 20, 2012 8:09:08

  42. @GarciaWebDev

    Allison, did you knew about these browser extensions? https://t.co/eoOKMOjB http://t.co/DkhFNCII https://t.co/PrEkYl64 http://t.co/HN2JF6wi

    Tue, September 25, 2012 12:09:44

  43. @davecranwell

    The main flaw with using nested rules too widely is the CSS specificity of the compiled selectors: mobile-last is hard http://t.co/9WLNqHx9

    Wed, September 26, 2012 8:01:30

  44. @jimniels

    Another amazing tool of Sass are its color functions. This is a great tool for working with them http://t.co/HjIkqj0t http://t.co/LUDekpeL

    Wed, September 26, 2012 8:28:06

  45. @JoelEade

    Another tick for SASS in my brain box. Just need to take a few hours and get it done! http://t.co/xHpXNs1h

    Wed, September 26, 2012 6:30:37

  46. @chrisdasie

    I've hesitated when it comes to using CSS preprocessors. But there are a lot of amazing benefits in using it. http://t.co/UDKG5SBh

    Fri, September 28, 2012 6:09:29

  47. @jina

    "HOLY TOLEDO THIS FRONT-END DEV IS SERIOUSLY SASSY AND LOVING IT." http://t.co/n1PW0vEK

    Mon, October 01, 2012 5:10:15

  48. @justincline

    Timely: “@jina: "HOLY TOLEDO THIS FRONT-END DEV IS SERIOUSLY SASSY AND LOVING IT." http://t.co/YLMqKHMf”

    Mon, October 01, 2012 5:14:38

  49. @jorgemancheno

    I know that feel. I've been using LESS for the last 6 months and going back to vanilla CSS is such a pain. http://t.co/LbRiqcz5

    Mon, October 01, 2012 5:32:37

  50. @redkitedesign

    Great article on moving to Sass - 10 months of trying it out: http://t.co/D7GdYmpy

    Mon, October 01, 2012 6:26:31

  51. @gregbenner

    Great article outlining the reasons to preprocess, the CSS.

    Wed, October 31, 2012 2:29:36

  52. @TechArchX

    Loving this !

    Wed, January 16, 2013 2:19:13

Copyright 1995–2013 Happy Cog™