Write better CSS with Sass and Compass using Visual Studio

I am pretty new to Sass and Compass, and I’ve experienced a learning curve with integrating it into my web development process. In this article, I’ll share my experiences with the technology and how I set it up and used it in a Visual Studio .NET environment.

Before Sass: The CSS Compromise

Writing CSS has always been an uncomfortable compromise between using presentational classes versus semantic classes. I often end up with a mix of the two, using semantic names when possible, and presentational names when I really want to avoid repetition of style definitions. Take, for example, this very non-semantic CSS class:

.inlineblock { display:-moz-inline-stack; display:inline-block; *zoom:1; *display:inline; }

This includes the necessary hacks to provide a cross-browser compatible implementation of the inline-block display mode. The benefit of this class is that I can define the rules for styling an inline-block requirement in one place only. The downside is that I need to clutter my markup by adding this class name wherever it is used:

<nav class="inline-block">...
<li class="popular inline-block">...

The alternative is to include the inline-block style definition directly within the semantic class names:

nav { display:-moz-inline-stack; display:inline-block; *zoom:1; *display:inline; }
li.popular { display:-moz-inline-stack; display:inline-block; *zoom:1; *display:inline; }

With this approach the CSS is less clear and harder to maintain, but my markup looks much cleaner without the presentational classes:

<nav>...
<li class="popular">...

Introducing Sass — Syntactically Awesome Stylesheets

Sass is a compiler for CSS that adds some very useful programming constructs to the CSS language. These enhancements increase the versatility of CSS tremendously, and can eliminate repetition within your CSS without making compromises to your markup. Sass supports nested rules, variables, formulas, built-in functions, and user-created functions (called mixins).

The main Sass syntax is SCSS (“Sassy CSS”). It also supports the original SASS syntax, which uses indentation to identify scope rather than the curly braces used by SCSS. Both “.scss” and “.sass” file extensions are supported by Sass, but the SCSS syntax is the recommended choice in most cases. Visit http://sass-lang.com to learn more about Sass.

Coming from a Windows/.NET development environment, I had no experience with Ruby, the language that Sass uses. You’ll need to have Ruby on your system for Sass to work, but setting this up was straightforward. Like me, you may work primarily in the Visual Studio IDE and are wondering how well Sass integrates. The quick answer is that 1) you execute a command line program that monitors a folder for changes and automatically recompiles Sass files when they change, and 2) you can configure the IDE to provide reasonably good syntax highlighting for the new file format. I’ll cover all the installation details in a bit.

Compass — Sass Implementations of CSS Best Practices

Compass is a rather impressive Sass-based framework. If you’ve worked with various CSS frameworks before, then you’re in for a treat with Compass. To quote from http://compass-style.org, “Using the power of Sass Mixins and the Compass community, you can apply battle-tested styles from frameworks like Blueprint to your stylesheets instead of your markup.” The main Compass installation includes a Core and Blueprint framework. Blueprint is a Sass implementation of the popular Blueprint CSS framework. I like this framework quite a bit, but as with any CSS framework, there are quite a few things I don’t like about it. I use it because I think it’s the best of the popular CSS framework out there, and it improves productivity on my projects. The rebuilding of Blueprint CSS using Sass is a thing of beauty though. The issues I have with Blueprint CSS just don’t exist in the Sass Blueprint framework. I can now selectively include the bits I want, customize many of the defaults instead of overriding them, and most importantly, be very semantic.

Compass seems to be a wrapper around Sass. The Compass installation also includes Sass, and the Compass command line programs replace the Sass equivalents. Compass also includes its own configuration file definition. When you’re getting started, you’ll be visiting the Sass website quite a bit to learn about the general syntax of the Sass language, and visiting the Compass website a lot to review the reference documentation for all the Compass Sass files that are available.

Using Sass and Compass

Doing things the Sassy way creates a kind of love / hate relationship, especially when utilizing Compass mixins. On the one hand, I am continually amazed at how clean my markup and Sass CSS files now are. Very maintainable! On the other hand, I seem to spend a lot more time trying to understand where the CSS is coming from and how best to aproach a modification. I think a lot of this is because I’m still learning about Sass and, in particular, Compass. As with any new technology, proficiency increases with experience.

Quite often I found that Compass mixins were not working in quite the way I expected. For example I used @include horizontal-list on a list to float the items to the left. I didn’t expect that right padding would be automatically removed on the last list item. I can see that being useful in some cases, but in my instance, I needed to retain the padding. Adding an override to re-introduce a padding I had already set was messy, so I ended up not using this mixin, and used some lower level mixings instead: no-bullet, reset-box-model, and float-left. Credit to the Compass documentation—there are links to the source for every mixin, so examining implementations and using selective bits is really easy. I also found Blueprint behaving differently than expected. My starting point was an existing website that was already using Blueprint CSS. I had hoped to drop in Compass with the Blueprint framework, and see what impact it had. I added class="bp" to my <body> tag, because it was recommended to include Blueprint scoped this way. This, however, resulting in many of my overrides no longer taking effect because the increased specificity of the Blueprint CSS classes was now a higher evaluation priority than my overrides were. Again, credit to Compass, the documentation explains clearly how to implement Blueprint with or without scoping, so the change was easy to make. Later, as I worked through my existing overrides, I found different ways of implementing them within the Sassy environment. For example, I no longer needed to override the link color. I was able to set it via a variable instead, and the Blueprint mixins used it for the generated CSS automatically.

One of the point of confusion was that throughout the Compass comments and documentation a plus sign is used as a shortcut for @include. It took a while to understand that this syntax is only applicable to “.sass” format files. It isn’t available in “.scss” format files since the goal of this format it to better align with generic CSS syntax.

Like many, I rely heavily on Firebug for reviewing applied CSS on the client side. Now that the CSS is generated, the new level of abstraction made making edits painful. Each iteration required tracking down the Sass file that generated the CSS by examining the comments in the generated CSS file. But then I found FireSass! This FireFox extension causes Firebug to report the Sassy files and line number rather than the generated CSS ones. Getting it to work isn’t as simple as installing the extension. You also need to make some changes to your environment. I’ve included those directions in this article.

Installation on Windows

First install Ruby. I used Microsoft’s implementation, IronRuby (http://ironruby.com). Alternatively, you can use http://rubyinstaller.org, which seems to work just as well.

Then download the most recent zip of Compass from http://github.com/chriseppstein/compass/downloads. Unzip the file into a folder, open a command prompt at the folder location, and type:

igem install compass

The only difference between this command and the one documented on the Compass site is that the command name is “igem” instead of “gem”. Since I used IronRuby, the command names have an additional “i” in front of them.

Open a command line to the folder of your Visual Studio project. You’ll want to be in the folder that is the parent of the folders containing your stylesheets and images. If you created an MVC project you’ll have a Content folder, which is most likely the one you’ll want. Type:

compass install blueprint/semantic

This will create subfolders, if they don’t exist, for images, stylesheets, and src. The new file config.rb contains all the configuration settings. You can edit this if you don’t like the default folder names, for example, I changed stylesheets to css and src to sass. It also creates the folder .sass-cache, which is used internally for performance. It’s a good practice to exclude this folder from source control commits and deployments.

The default “.scss” files include some examples and useful comments. It’s worthwhile spending some time becoming familiar with what’s there and understanding the syntax. Before you start editing, run this command in the folder containing config.rb (or specify a path as the command argument) to monitor your file changes and automatically regenerate the CSS files for you:

compass watch

Adding SCSS Syntax Coloring to Visual Studio

You can add SCSS syntax coloring to Visual Studio by mapping the “.scss” file suffix to the “CSS Source Editor” in Visual Studio. This works quite well since the syntax of SCSS is so close to CSS, although it breaks down a bit on nesting, and it works best if you stick to the /* ... */ commenting notation rather than the // one that is included in the examples. It isn’t possible to make this configuration change through the UI, but I found this extension that applies the necessary registry changes. As noted on this site, be sure to exclude and re-include SCSS files belonging to any existing projects for it to work on existing files.

I also turned off CSS error detection in Visual Studio to get rid of the green squiggly lines below much of the text. That option is in Tools -> Options -> Text Editor –> CSS. Uncheck the “Detect errors” checkbox.

Installing FireSass

First install the extension, then add the following line to your config.rb:

sass_options = {:debug_info => true}

Delete your generated CSS files before running compass watch to force regeneration with FireSass debugging information. I don’t recommend enabling the debug_info for your production website, because the generated CSS cannot be correctly parsed by Internet Explorer.

Final Thoughts

In much the same way that jQuery redefined the approach to JavaScript programming, so Sass does for writing CSS. Compass and Sass collectively bring a lot of goodness to web development. In my mind here are the main pros and cons of using them:

Positive:

  • HTML not littered with non-semantic classes (especially when using framework such as Blueprint CSS)
  • Avoid duplicating common CSS patterns
  • Accomplish predicable changes by write formulas for dimensions instead of “magic numbers”
  • Consistent application of common workarounds for broad browser support (via Compass Core)
  • Avoid repetition of browser-specific CSS3 style rules (via Compass Core)

Negative:

  • Learning curve to become proficient (but same with any new technology)
  • Layer of abstraction created by mixins and included files can slow down CSS debugging

8 thoughts on “Write better CSS with Sass and Compass using Visual Studio”

  1. Thanks for a great blog post. I am working through this now – but can not find the config.rb
    >>The new file config.rb contains all >>the configuration settings.
    I ran compass install blueprint/semantic on the content folder and have the folders mentioned but can not find the config file. Any idea where it should be?

Leave a Reply

Your email address will not be published. Required fields are marked *