Improving Your Process: Segmenting your Sass as a Method of Optimization

I think it’s safe to say that I’m fully hooked on Sass. I was reviewing my earlier reaction and came to realize that my assessment of what was useful and what wasn’t turned out to be a bit preemptive. As I became more accustomed to working with Sass I would find myself in situations where a feature I once thought was obscure seemed to fit the bill perfectly.

One such case was with a site I needed to build a decently sized image sprite for a number of assets throughout the design. As I was coming up with the mathematical formula for the placement of each additional element within the sprite, it clicked. This is where I can use my first Sass formula. Instead of having to figure out the desired coordinates every few minutes, I could instead set an index variable and run that through a function to retrieve the needed pixel values. Awesome.

Also: Compass

Compass comes across your radar pretty quickly when getting into Sass. In my usual style, I strayed away at first in an effort to learn the technology behind the framework. After a short amount of time, I realized that Compass was doing exactly the same thing as I was: coming up with generalized mixins that I could carry around with me and use at my leisure.

Needless to say, once I was comfortable with Sass, I was quick to adopt Compass and use quite a bit of what it has to offer. Without going into too much detail and turning this into some overzealous rant against frameworks I’ll leave it at that. What I like most about Compass is the level of availability it’s created. It gives you tons of utility mixins without stepping on your toes and forcing you to conform to a specific way of writing Sass. Even the layout mixins made available are aimed at being a utility as opposed to creating a rigid structure.

CSS segmentation

The latest piece I’ve put into practice is nothing ground breaking or new, but it’s something I once said I’d never imagine myself doing. In the last few projects, I’ve been segmenting my stylesheets into separate files, and that’s all thanks to Sass.

Back in the day, there was a camp that fought fervently to stand behind the opinion that separating your stylesheets is a great way to organize yourself and keep your styles on track. Very often you’d see various rules for separating files but most of the time they’d be broken up somewhat like so:

• Structure
• Typography
• Colors
• etc.

The targeted styles would be incorporated as per the file name and they’d continue that way. I initially took offense to this method. At the core I didn’t like the idea of having to open (at least) three stylesheets to add a new element to the design, and it felt like maintenance would be super frustrating. Additionally, I didn’t like the idea of having so many HTTP requests for these separate stylesheets either. It seemed like a waste.

Sass changed that for me. I’ve been segmenting my stylesheets for the past couple of months and I’ve got to say I really like it. Not only that, I think it’s helped me to write better optimized CSS without having to focus on doing just that. Allow me to explain.

Sass stylesheet segmentation

To reiterate my previous ‘issues’ with stylesheet segmentation, they are as follows:

1. Maintenance woes
2. HTTP request bloating

While they may seem trite, maintenance and optimization factors are what mark us as professionals. We sweat the details. We can knock HTTP request bloating off the list straight away thanks solely to Sass’ @import. Using @import we can concatenate our files and serve a single stylesheet right out of the gate. Problem solved.

Maintenance is another issue, however. There was something that still bothered me about separating out stylesheets and for me it came down to the rules for separation. After reading SMACSS it clicked. Instead of splitting up selector properties per file, group selectors based on their use. A typical screen.scss for me now resembles something like:

// variables used throughout the site
@import "variables";

// miscellaneous modules used throughout the site
@import "global";

// structure definition
@import "structure";

// layout sections
@import "header";
@import "footer";

// sitewide copy styles
@import "copy";

// page specific
@import "home";
@import "services";
@import "products";
@import "contact";

This screen.scss is preprocessed to screen.css and that’s the only stylesheet sent to the client.

I’ll begin with having a single file used for variables. To date, variables I use consist of color definitions and that has been extremely helpful throughout my workflow. Next I’ve imported a global stylesheet which includes utility classes put in place throughout the site. Here’s where your clear fix would go, your button styles that carry through the design, and any other global patterns you recognize.

The structure stylesheet is the scaffolding for the design on every page. It sets up your grid and places things to be used on each and every page without getting into much detail. The header and footer stylesheets are the detailed rules for each respective section. The last of the ‘general’ stylesheets controls the copy. Rules in this stylesheet target only the main copy area, for example a blog post. These rules do not apply to fonts used in the header, footer, or sidebars, but instead encompass the most generic use of copy you can think of. Here is where you define rules for headings, lists, special image classes, etc. based on the assumption that any content block could inherit these styles.

The last group of imports encompasses the page specific stylesheets for the site. Each screen of the design is given it’s own style sheet, and the key here is to make sure that the styles within apply only to that screen. I’ve found that having this mentality forces me to better determine candidates for global.scss which in turn helps you write more adaptable CSS.

It’s important here to keep in mind that your CSS is going to be preprocessed. One major factor with that is the ability to comment to your heart’s content. When files are segmented things can become disjointed to a team member or even to yourself when it comes to maintenance. Avoid confusion with helpful comments, they’re going to get stripped out anyway. Leave yourself notes if you’re extending something in global.scss so that you don’t duplicate things. Do what you can to get yourself in the same mindset as was present when you first architected this whole thing.

It’s about patterns

One of the main reasons I enjoy front end development so much is pattern discovery. The better you are at discovering patterns, the better your front end will be. I think this method of stylesheet segmentation helps advance that ability. If you’re able to effectively segment what truly belongs in a page specific stylesheet and generalize what doesn’t, you’ll be writing a lot less CSS, and that’s the name of the game.

Once you’ve written your variables, structure, header, and footer you’ll be surprised at how much can be reused on subsequent pages. Even styles you thought would be page specific will likely overrun some bigger pattern and result in the creation of a global pattern with a specific property in a couple of circumstances. Design has many patterns, and the better you’re able to take advantage of that, the better your front end.

My focus for the next few months will be to be more conscious about the selector I’m styling. Is there a pattern? Can it be generalized to global.scss and specified here instead? I want to streamline my CSS as much as I can without abstracting so far to oblivion the structure becomes meaningless. I want to see if that helps me complete tasks faster. I want to see what effect it has on render performance. I want to see how this process works when working on a team. I can’t wait to reflect on the results.