CSS has been a hot topic in our industry for literally as long as I can remember. I say that because I was thrown into the deep end with CSS when I became “a professional”. To clear up any possible misconception about what that may mean: I consider my professional development career beginning on my first day of a paying job comprised mostly of markup and style. Of course I wrote HTML many years before that, but that was a learning phase. When you’re hired by someone you hadn’t personally known before the first job interview, that’s when you went pro. Or freelance. Details, details.

CSS has been and will continue to be a major talking point because it’s awesome. People are enamored with CSS and it’s a wide open playing field for innovation and improvement; something many people have gravitated to. Tons of innovation has taken place in the CSS space alone, and with CSS3 being so widely accepted and [quickly] adopted, it continues to be an exciting place to watch from day to day. We’re finally seeing one of the largest benefits of CSS come to fruition on a huge scale: context independence. In fact, that’s where the most exciting stuff is taking place currently: responsive Web design (usually) based on media queries.

Just as exciting as watching what we can do with CSS is watching how we can do it. Talking about tools is a touchy subject, but I can’t help to try and keep both the quality and speed of my work in check. I was well into my professional career before I realized what a large effect snippets would have on nearly every line of code I write.

Then there was zen-coding. zen-coding hasn’t truly stuck as being integral, but it forced me to look at what I was doing from a hugely different angle than ever before. Point being: I don’t want to miss or prevent something like that from happening by becoming too comfortable in my own environment. I see it as keeping me on my toes, and that’s super important to me as I continue trying to hone my craft and do the best job I can do.

Processing CSS

CSS processing isn’t a completely new idea. I spent some time a few years ago experimenting with what I came to call adaptive templates that were based on CSS live-processing that did little more than allow me to use variables in CSS via PHP. I thought it was great; for a minute. Then reality got the best of me and I realized I was using layers of hacks at a time when simply swapping out a body class (which is more appropriate for PHP as it is) would have done just fine. It changed my thinking though. It was a living use case causing the seed to be planted planted: CSS might not be doing quite enough.

CSS processors became even more advanced. As with everything new, people went nuts combining PHP and CSS and many monsters resulted. The fact remains though, that people were thinking beyond CSS.

I believe that from the mayhem of live-processing CSS documents came a much smarter goal: CSS preprocessing. That is to say, instead of parsing a pseudo-dynamic, PHP-based CSS file on every request at runtime, the file was generated before deployment, leaving all the work to be done at a single point in time, on the development machine instead of within a production environment. This made much more sense not only in practice, but also concerning server resources as well.

Enter Sass

Two big players came out of the consensus that if anything, preprocessing was the way to go: Sass and LESS. At my first glance, Sass seemed much more straightforward, and much more talked about in the circles I follow. When I polled around, Sass was a near-ubiquitous winner as far as votes were concerned, so I’ve devoted the past few months to working primarily in Sass with my full scale projects.

I’ve only worked with Sass in recent months because I simply wasn’t a fan of Sass prior to Sass 3.0 which brought us SCSS. When I first took a peek at Sass, the syntax was a major turnoff. While it mostly made sense, and I could see that minimalism was a focal point, I didn’t like the huge departure from CSS itself and held off on diving in.

Upon reading about the availability of Sass 3.0 and SCSS, my interest was again ignited. It still felt like I was writing CSS, and I wasn’t looking to stray completely away from it, just write it a bit faster and possibly be a bit organized.

I had my fair share of reservations though. Without looking into it, Sass felt like it would inherently spit out exorbitant amounts of extraneous CSS, something that never sat well with me. I’ve worked for some time to try and make my CSS as lean as possible, and this much automation made it feel like I would be taking a step backwards for the sake of some preprocessing sweetness I didn’t really need but thought might come in handy. I think, for the most part, I was wrong. As with most things, it all comes down to how you use it. If you’re using Sass intelligently you will save yourself time, keystrokes, and retain a highly optimized end product all at the same time.

I can’t emphasize enough how it was only the inclusion of SCSS that had me initially take an honest look at Sass; I’m really glad it has made it’s way in to the shipping versions of Sass. I’ve now completed four full scale projects using Sass and only now do I feel comfortable outlining what I like, what doesn’t fit, and what I don’t care for when it comes to a CSS preprocessor.

Primary benefits of Sass (for me)

I’ve found over the past few months that there is a primary set of benefits to my using Sass. Beyond that there is a secondary set of near byproducts that I hadn’t really sought after when first using Sass, but noticed along the way. Finally, there are some features that simply don’t fit for my workflow and go to the point of my almost wishing they weren’t there.

Nesting

There’s something about nesting. At first I found it clunky. After all, I am (was?) a single line CSS zealot. The major reason I prefer[red] single line CSS was readability. I was able to scan a 500 line stylesheet an order of magnitude faster than a 2000 line sheet. Trying to scan a multiline stylesheet resulted in a noticeable slow down for me, so I stuck with single line and made some changes to boost readability even more. While single line is all well and good in Sass 3.0 thanks to SCSS, it pays off if you switch to multiline for readability. Nesting comes second nature and saves you specificity keystrokes along the way, consistently.

A side effect of switching from single line CSS to multi line SCSS was that I’m for the first time taking advantage of code folding (for now). You can fold entire blocks of SCSS nests, which makes scanning and making maintenance changes exponentially easier. If you were ever a CSSEdit user, you can think of native code folds in SCSS as equivalents to the ingenious pseudo-folders implemented by MacRabbit. I always loved that feature of the app, but never got around using a separate app to write CSS.

Mixins

I have come to love Mixins for a number of reasons. CSS is full of patterns and mixins help you take advantage of that like no level of OOCSS can (at least considering how I use OOCSS). Standalone mixins are great, reusable code snippets that can be injected using a simple property: value; combination.

Things are taken one step further, however. Mixins are able to accept arguments as well. The CSS naturalist in me hated it, but the client-focused developer in me loved it. By the time my first project was complete, I had a number of reusable, generalized mixins that I continued to use in subsequent projects.

Here’s the kicker though: I’ve never been able to successfully build a collection of reusable CSS snippets that I could carry along with me in my CSS framework, but Sass allows for it.

Without Sass, sure, you can include your CSS snippets in a couple of ways. You could keep your snippets at the top of your personal boilerplate stylesheet and use them as you go about front end development. Trouble sneaks in there with the fact that unless those snippets are trimmed prior to deployment, you’re wasting (what could amount to) a significant percentage of total bandwidth for that stylesheet on unused selectors. Alternatively, keeping track of what you’ve used and not used is just one more step you need to remember to remove just prior to deployment. You could technically keep your snippets in their own stylesheet, and pull from it (literally by copying and pasting) as you found a need for a snippet. That just smells like maintenance trouble.

Sass solves these issues. Upon compilation, a resulting Sass-generated stylesheet will include only the mixins that are actively used in the stylesheet. This means that we can build an entire library of mixins for use over time, include them within our personal framework for easy access, and they’ll be trimmed out if we don’t use them. So far, I’m hooked on that.

Parent References

This is a wicked small (sub)feature but it’s something I’m conscious of using every time I do. When writing CSS, especially concerning CSS3, you often want to use pseudo selectors. Even prior to CSS3 we were using pseudo selectors like :hover and :active all the time. Sass makes this super simple via Parent References, a special character allowing you to reference the current working nest level and create additional rules as you go along.

Secondary benefits of Sass (for me)

A number of major callings to Sass have had a primary effect on the way I write CSS, but there are some outliers that come into play as well. Some I had planned for and think are nice, but others took me by surprise and I’m glad they did.

Variables

CSS processing, from what I can see, mostly originated from the desire to include variables within your CSS. Variables, as we’ve discussed many times, would be most useful when it comes to colors. There are a couple of reasons that variables are really useful in CSS.

1. Consistency — You’re positive that a likely copy and paste fumble won’t happen
2. Redundancy Removal — Instead of referencing your color glossary or otherwise, you can use a plain English variable name instead of a hex code throughout your stylesheet
3. Easy updates — No more Find all and replace, you only need to edit one line

Variables have been useful for me, but for little more than color definitions.

Automatic compression

Performance on the front end is rightfully a hot topic, and will continue to be so as the mobile space continues to explode. Sass allows for automatic compression on various levels during processing. I love this.

Comment variants

Sass brings two flavors of commenting to CSS. The kind that make the cut and the kind that doesn’t. I’ve become a big fan of this because there are certain comments that make sense to leave for deployment, and other (mostly superfluous) comments that make sense to leave for development. I can be much more liberal in documenting my Sass knowing that it’ll be cleaned up during processing. At the same time, you can tell Sass to leave in certain comments such as attribution and other details that may be useful to someone dissecting your work.

Importing

Sass has refined CSS’s native @import to reduce the number of HTTP requests and instead import the appropriate content when processing. I’ve become a fan of this feature because it helps facilitate my front end boilerplate. I’m able to include a base stylesheet and a reference to my collected mixins, and not do a thing to clutter up my project-specific stylesheet. Upon save, the three files are combined and generate a single document resulting in one HTTP request.

What I don’t use

I use quite a bit that Sass has to offer, but there’s even more that I don’t use and likely won’t use. Sass is at version 3.1.3 at the time of this writing and been under heavy development since its inception. They’ve done some amazing work and responded to many real world needs and wants from their community. With that, naturally comes features that we won’t all use. More on that later.

I’d like to mention a number of features that simply don’t fit with my workflow. Please don’t see this section of the article as my outward distaste for Sass. I simply have a different thought process when it comes to handling some of these situations as they come up. The Sass team has chosen to give their community the option to lean on the preprocessor to do certain work for them, and I’ve chosen to lean on other methods.

Selector inheritance

Sass offers selector inheritance via @extend. I’ve found it better in practice to make use of OOCSS and have the leg work be done there as opposed to in the CSS preprocessing layer. Sass is smart about it though. One of my original concerns about using a preprocessor was the generation of extraneous style declarations that bloated the resulting stylesheet, but Sass takes that into account with things like @extend and will intelligently combine the rules into something optimized. I like that.

SassScript, particularly Operations

When I first read of SassScript I honestly disregarded it. At first glance it seemed superfluous to me and didn’t make sense as part of the Sass specification. Over time I realized it was simply my zealousness and took a closer look at it. SassScript is interesting in that it could potentially save some keystrokes once you’ve mastered it, but it’s not something I plan to focus on as it seems problematic for maintenance with the way I work.

There is definitely some neat stuff going on with SassScript, and I hope to some day read a few pieces on applicable usage to get more scope and context concerning the inspiration for it’s inclusion.

Everything else (so far)

All of these features and I still haven’t covered it all. Sass is a workhorse with plenty of tricks. I hope to tackle a few as time goes on, but I feel that I’m comfortable with the changes I’ve adapted. I think that incorporating Sass into my workflow at the level I have will facilitate equal quality work at a faster pace.

It seems like a decent segment of the remaining Sass features are better suited to designing in the browser and do a fantastic job at facilitating such a workflow, but my process involves receipt of client approved static design comps, so some things simply don’t make sense for me.

Where it hurts

Sass has been a really interesting ride. There were times where I thought I’d simply give up on it, that it’s too ‘proprietary’ given the nature of CSS and that I didn’t want to deal with it. Something about it though, had me try it with “one more project, to make sure my opinion sticks”.

The biggest hiccup for me when working with Sass is maintenance on a production environment. With Sass, you now have (at least) two files to make sure are up to date when any changes are made: the original .scss document, as well as the resulting .css stylesheet.

This frustration comes down to some bad habits I’ve picked up over time though, and I’m glad to have been put in a place that forces a resolution. I shouldn’t be editing stylesheets in such a way where it prevents my process of preprocessing, I should have a process in place that takes account the fact that my projects are under source control and I have deployment procedures that should circumvent any issue that comes up from having CSS preprocessing in the mix.

Admittedly (and embarrassingly), the core frustration comes from my tendency to make a really quick edit in a production environment and once complete, I’ll replicate that change in the repo. It’s a terrible habit I’ve become far too comfortable with.

My conclusion on Sass

I’ve given Sass a proper tire kicking. That tire kicking involved the production of four full scale websites over the course of three months. This process took a project from initial markup and style all the way through maintenance phases, so I feel I have a strong grasp on how Sass affects my workflow.

As with all things, you need to have a plan and you need to play it smart. Sass can quickly spiral out of control into a mess of spaghetti bloat that does nothing but create a mess on literally every level. On the other hand, Sass can make writing CSS beautiful. You’ll need to take the time to effectively evaluate circumstances and outcomes and learn how your decisions will change things down the line.

As of now, I’ve fully integrated Sass into my workflow and plan to continue to research methods of saving time and effort while retaining quality. I plan to document these discoveries here, likely discovered ten times over by Sass veterans. I hope to show that Sass is worth an evaluation of your time, as the byproducts could be a great boon to your productivity.

Compass and more

Sass opened the doors for many things in addition to a big change in the way we write and maintain our CSS. Additional tools have come as a result of Sass, one of the more popular being Compass which is an open-source CSS Authoring Framework. Compass has done what I’m looking to do with my own project boilerplate.

While not directly related, the other avenue to explore when getting into Sass is Haml. The goal of Haml is to essentially beautify and facilitate writing HTML by avoiding inline code. Haml is a topic of discussion well outside the scope of this article, but worth researching a bit to see if it’s for you.