sean! the blog

A CSS playground

I like to get SASSy

So, I was planning to work up a post comparing some different grid design systems, and then I realized that the one I’m spending most of my time with, Semantic.gs, relies on the use of a preprocessor. Specifically, Semantic.gs is built to run on LESS, but it works just as well with SASS (which, as luck would have it, is what I prefer to use).

It made sense to me, therefore, to first explain a) what SASS is and b) how I use it.

What is SASS?

At its core, SASS is a CSS preprocessor that lets the user write shorthand code that is compiled into long-form CSS. It’s a time-saving tool that gives more power and flexibility to the front-end developer and extends the functionality of off-the-rack CSS. After having only used it only briefly, for a few minor, experimental demos, the benefits are wildly apparent. It incorporates features and capabilities that seem like they should be basic CSS features, without positioning the user behind a prohibitively steep learning curve. It seems to take many cues from the world of programming language, but even a web developer with no previous programming experience could quickly pick up on SASS’s rich feature set.

So, what can I do with it?

Without diving into the world of tutorial (of which there are several), SASS affords its users numerous benefits over stock CSS. Among these are features like variables and nested selectors.

Variables allow the user to assign a value to a specific predefined string, and then use that string elsewhere in the code. Say, for example, that you want the background color of half a dozen page elements to be #3C3C3C, but you may want to change it later. Stock CSS would require that you spend the time to pore through your code and find each and every instance of that color in order to change it. SASS lets the user define that color once with a variable, and then call to that variable as many times as necessary later.

$bgcolor: #3C3C3C;
.mainContent { 
background-color: $bgcolor; 
} 
.sidebar { 
background-color: $bgcolor; 
}

The user can then use functions to modify those variables, which help to keep a consistent color palette across a site.

.sidebar { 
background-color: $bgcolor; 
border: darken($bgcolor, 10%); 
}

This gives the sidebar element a background color of #3C3C3C with a border that is a slightly darker grey. If the color scheme changes to green, the only line of code that needs to be changed is the first one, where $bgcolor is redefined to something like #6B8E23, and every property that calls that variable will instantly switch to green.

Of course, this is only a fraction of what can really be accomplished with SASS. The feature that I am most intrigued with, though, is the way it handles imports of other stylesheets.

The other big big big feature is the @mixin function, which works sort of like variables, but with entire chunks of code. This is how more complicated frameworks can be used with SASS and really supercharge how you write CSS. To explain the whole concept would take an entire new blog post, so I’ll spare the details.

Traditionally, if the developer wants to break a master stylesheet out into smaller, separate fragments, the options are either use @import to drop them all into a single stylesheet and suffer the performance hit due to multiple http requests, or some other equally painstaking workaround with suboptimal performance. This is where, in my opinion, SASS really shines. What follows is a feature that is only really briefly touched on in the documentation, but which seems to me like the real selling point for this tool.

Tell me, Sean, how do you use SASS?

My primary stylesheet (by which I mean my primary SASS stylesheet, the .scss file that I modify directly) consists of only five lines of code. Each of those five lines calls to a separate stylesheet that styles only specific aspects of the page. Those five separate stylesheets are all housed in the same directory as style.scss, my main stylesheet, but they are all named with a preceding underscore, which tells SASS that these are a specific type of file meant to be imported. Two of these imported stylesheets sit untouched, and implement specific default conditions. The other three are the ones that I modify myself, which provide presentation style to my site.

Imports in SASS

My five imported stylesheets

The five stylesheets I use are _reset.scss (Eric Meyer’s reset stylesheet), the previously mentioned Semantic.gs (which I named _grid.scss), my layout sheet (_layout.scss) which includes my positional properties like margins, borders, and padding, my color sheet (_color.scss), and my typography (_type.scss). It’s easy to see how it’s broken down so that each aspect of the code is compartmentalized and can be modified independently. The great thing about this system, though, lies in how SASS handles these @import sheets.

Instead of linking to each of these pages separately in a master stylesheet, in production all of this code is combined into one single sheet. SASS knows that if I import my layout stylesheet, I want all of that code to be implemented in my corresponding CSS document. So when I say @import "layout" in style.scss, SASS automatically takes all of the code present in _layout.scss and dumps it into style.css, my production stylesheet. Ditto “_color” and “_type” and all the rest. Five discrete stylesheets, all concatenated into a single sheet in production. Like magic.

Full expanded CSS

Fully expanded CSS from five lines in SASS — magic!

Admittedly, the tradeoff is that I now have three stylesheets that I have to manage (layout, color, and type), but that also means that I can modify any of them all I want without any impact on the other two.

Putting it all together

All of these features are nice and all, but it really doesn’t do anyone any good unless there’s a simple, usable system in place to implement everything as seamlessly and painlessly as possible. At least, that’s my opinion. I think of myself as being pretty good at computer and all that; I can manage some basic command line functions and diagnose your run-of-the-mill error, but I’m no guru. I don’t do Ruby, which I think is a major hurdle for most of the people who consider using a preprocessor like SASS and then shy away. Fortunately, once you’ve got everything set up (which requires, I think, two commands at the command line) there are ways to automate the rest of the process. The tool I found most useful is an application called Scout, which lets you plug in your source (style.scss) and destination (style.css) files, then watches for changes and makes updates automatically.

Screenshot of Scout.app

.scss goes in, .css comes out — it’s like a STYLE FACTORY

This way, whenever I make changes to my development stylesheet (style.scss), those changes are instantly reflected in my production stylesheet (style.css) without any additional input from me. That means that whenever I update any of my linked stylesheets (for layout, color, typography, or anything else I might need to add for my project), style.css is perfectly in step.

This is really just a very brief overview of how I organize my stylesheets and use SASS and Scout to speed up my development process. Like I said earlier, entire catalogs of posts could be made to really dig into the nitty-gritty details of using SASS and all its functions, but that’s far beyond the scope of this blog (and in many cases, the scope of my ability so far). Hopefully I can further expand on this arrangement and really optimize how I’m putting pages together, but it’s working pretty well for me so far. Time will tell, though, and I may find myself combining everything back into one stylesheet in SASS instead of dealing with separate “aspect” sheets. Like everything else about web design, it’s still a work in progress.

Advertisements

Talk to me!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: