Test driving Sass 3…a second look at Sass

Sass logoSoooo…I have decided to try my hand at updating my install of Sass to version 3. I’m just a simple cave man…but I do know one thing. THAT was a bitch. I am stupid when it comes to command-line stuff. I literally have to do a google search on everything that I try to do. I have 10 windows open at the moment and each one is something dumb. Like how to change directories, how to update a damn gem, how do I update compass, how do I recompile with compass….COME ON!

Whew! Its done. And it works. Thank GOD! Now first I am going to give you a link to the test page I am building (using the html from my “Creating your own tool kit – Part I: CSS” post).

Click here for the demo.

Let’s take a look at the Sass first. Keep in mind, this is basic Sass stuff, but I want you to see the cool factor. Sass 3′s main syntax is SCSS (Sassy CSS). It is more closely related to CSS than Sass 2 was.

NOTE: I wrote an article a while back about Sass, but that was using version two’s syntax, so I am basically starting over.

Sass code:

$gray: #666666;
$orange: #ffa100;
$green: #b1f100;
$blue: #0f4da8;
$darkgreen: #739d00;
$margin: 0px;
$padding: 0px;
$family: Arial,Helvetica,sans-serif;
$boldtext: bold;
$size: 14px;
$c: center;
@mixin marginall($numbers) {
  margin: $numbers;
@mixin paddingall($padnumb) {
  padding: $padnumb;
@mixin navlist {
  ul {
    text-align: $c;
  li {
    list-style: none;
    border-right: 1px #000000 solid;
    display: inline;
  a {
    @include paddingall(0 5px);
body, p, ul, ol, li, h1, h2, h3, h4, h5, h6 {
  padding: $padding;
  margin: $margin;
body {
  color: #ffffff;
  font: {
    family: $family;
h1 {
  color: $green;
h2 {
  color: $darkgreen;
a {
  color: $orange;
  outline: none;
  font-weight: $boldtext;
a:hover {
  color: $blue;
#container {
  width: 1000px;
  @include marginall(20px auto);
  @include paddingall(20px);
  background-color: $gray;
  overflow: hidden;
#header {
  width: 980px;
  background-color: $green;
  @include paddingall(10px);
  text-align: $c;
  @include navlist;
#content {
  float: left;
  @include marginall(20px 0);
#sideBar {
  width: 200px;
  background-color: $orange;
  float: right;
  @include marginall(20px 0);
  @include paddingall(5px);
  text-align: $c;
    h2 {
      color: #ffffff;
#footer {
  color: #000000;
  text-align: $c;
  font-weight: $boldtext;
  @include navlist;	

Before I explain ANY of that crazy, look at the CSS output:

body, p, ul, ol, li, h1, h2, h3, h4, h5, h6 { padding: 0px; margin: 0px; }
body { color: #ffffff; font-family: Arial, Helvetica, sans-serif; font-size: 14px; }
h1 { color: #b1f100; }
h2 { color: #739d00; }
a { color: #ffa100; outline: none; font-weight: bold; }
a:hover { color: #0f4da8; }
#container { width: 1000px; margin: 20px auto; padding: 20px; background-color: #666666; overflow: hidden; }
#header { width: 980px; background-color: #b1f100; padding: 10px; text-align: center; }
#header ul { text-align: center; }
#header li { list-style: none; border-right: 1px #000000 solid; display: inline; }
#header a { padding: 0 5px; }
#content { float: left; margin: 20px 0; }
#sideBar { width: 200px; background-color: #ffa100; float: right; margin: 20px 0; padding: 5px; text-align: center; }
#sideBar h2 { color: #ffffff; }
#footer { color: #000000; text-align: center; font-weight: bold; }
#footer ul { text-align: center; }
#footer li { list-style: none; border-right: 1px #000000 solid; display: inline; }
#footer a { padding: 0 5px; }

Comes out nice and tight! Doesn’t look like much right?

So what is going on under the Sass hood? Glad you freakin’ asked, cause I didn’t just do that for nothing. All the lines at the top with the ‘$’ next to them are variables. Any time I want to use the color #b1f100, I just say: color: $green. Easy as pie, right?

Onto the next part, and this is part of the coolness. The blocks of code that have the ‘@’ in front of them are called mixins. It is basically a block of reusable CSS. There are times where I use a lot of the same CSS in list navigations. Like the ‘ul’ margin and padding, the list-styles on the li’s, padding on the a tags…basically anything that you would reuse repeatedly, you could use a mixin.

The main one that you see is the navlist. That is basically calling out all the styles that go with the ul. So, if you look at my header and footer Sass code, you will both see that they have the inlude navlist in it. If you look at the demo page you will now see they will have the same type of menu. I could then go and change colors and whatever. You can even do mixins within mixins, which I did writing the styles for the list…you will notice the ‘a’ is being styled with the padding mixin.

This was all basically in one night, which I have to say, is quite freakin good. I used some of the basic stuff in Sass, using the SCSS (which most web designers will catch on to quickly): mixins, nested elements, and variables.

Now, does seeing what Sass can do make you want to go out and learn it? I’m going to go with probably not unless you are obsessed with web development like I am. Now that I’ve actually tried to build a little using it, here are some thoughts I’m having.

First, the good. It was fun as hell to start learning something new. Took me a while to get it installed and working correctly, but after about 20 minutes of using Sass, I was really starting to get the hang of some things. The learning curve on actually using it is pretty low, so that is a good point.

The variables are awesome. I can never remember what hex codes I’m using, so to able to assign them to a color name and just call that instead, is really bad ass. Also like nesting elements within elements, that is actually something I wish CSS had a while ago.

Now, the not so good? Mixins are cool, but I really didn’t see myself saving that much time by using them. Ok, my padding and margin mixins are bad, because I could have literally typed out the numbers just as quickly as calling the include, but, I’m not sure I reuse that much css to make them worthwhile, where a variable wouldn’t work better.

I’m going to conclude here and say that it was TOTALLY worth it to use it. I’m pretty sure I will use it for my next side project for the main build, then just edit the CSS file for the changes. If I have inspired you to try it out, please let me know what you think of it.

Nathan W., if for some reason you read this lowly blog, I would GREATLY appreciate your thoughts on the pros of using Sass over CSS, what a good editor would be to write it in, and what other things in Sass should I look at besides the basics that I’ve tried tonight! You would be awesome!

Coupon Code: webmachine

jQuery junkBox

This method attaches a handler to an even for the elements, which is executed once at the most.

$('#clicketyclicker').one('click, function() {

Tags: ,

13 Responses to “Test driving Sass 3…a second look at Sass”

  1. Jeremy, I’m having a hard time understanding the benefits of sass. The color variable thing seems nifty, but that seems like it could be done with PHP pretty easy. I know I’m missing out on what it’s all about, so I was just wondering if you could summarize. Thanks!

  2. jcDesigns says:

    I don’t know about the PHP thing, but I am with you on not quite getting the benefits. I did this because I read about it, saw some cool features in it, and decided to try it. I did this small trial to see what it could do, and I am not sure if I am just touching all that it can do. That is why at the end I was begging the current designer of Sass to come and comment. He has been here before, and his input would be greatly appreciated. I just might email him, and we’ll see what he has to say about it.

  3. Well since this is a compiler of sorts, having $black be a string of “#000000″ output to a stylesheet of style.php that has a header for css wouldn’t be very difficult.

  4. What I think would cool would be a compiler of sorts that will go though and find double margin bugs and what not.

  5. Sass is much more than just variables. You can see mixins demonstrated in the styles above; it also has support for functions, selector inheritance, scripting, and more.

    The goal of Sass is to provide a means of abstraction for CSS. I’d recommend reading http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters/ for a thorough take on this, but I’ll give a brief overview. When stylesheets get large, they get hard to maintain. There are a lot of parts that interact. Sass helps you separate this tangle and most importantly factor out re-usable components.

    This is definitely the most important aspect of Sass: it allows re-use within stylesheets.

    It’s true that PHP could do some of this. However, you don’t currently use it, and if you did it wouldn’t be very pleasant. Why? Because PHP doesn’t understand CSS. It isn’t able to make a color more transparent, it doesn’t know how to nest selectors, it can’t make one selector inherit another. All it can do is textual substitution. Sass, on the other hand, knows how CSS works and works with it, to make designing stylesheets much easier.

  6. jcDesigns says:

    Nathan, again, thank you for posting. Not sure if you read my comment on your blog to come, or if you just found, but either way, awesome of you to drop by. That is a great article you linked to.

    I think one of the things that I like about it is the maintenance aspect. The article points it out perfectly with using the variable. Let’s say you wanted to change the font color from black to gray. You can’t do a find and replace for #000000, because who the hell knows what that will change in the CSS. You could be changing border colors, or drop-shadows or who the hell knows what. But if you assign black to a variable like $fontColor, and just change that, it will only change the styles that are calling that variable.

    Sass might take a bit longer to read, but it makes more sense just looking through it in what it is doing.

    I find it odd that some of the comments in that article from people that don’t want to use it, stem from a fear of having to learn something knew or to learn a “coding language,” which it really isn’t. Just a new way of writing CSS. I think the people who “design” websites, rather than ones who “build” are the ones that are shying away from it.

  7. I’ve been using a similar CSS compiler called LESS CSS. It is not quite as feature rich as SASS and Compass, but the idea is very similar. I am currently working on a large scale web application and have found these techniques to be quite useful.

    There are three features that I have thoroughly enjoyed so far. Obviously variables (or constants) are quite handy. The nesting of elements is more useful than I would have thought, because it allows me to keep the styles more organized. For instance, all of the styles for a slide show component can be held in one block. The mixins are also fantastic for using vendor prefixed CSS features. Things like rounded corners or CSS3 gradients require several lines of code because one has to account for the “real” CSS3 property and the various browser prefixed properties. The mixins also allow one to write more semantic HTML. For example, instead of having a class in your HTML called “clear-floats”, “horizontal-nav”, or “striped-table”, you can make a mixin of it and attach the “clear-floats” directly to the element in the style sheet, leaving the HTML free of non-semantic class names. It really makes a lot of sense.

    For those that are afraid to get their feet wet, it is no where near as complicated as learning a new language. Learning PHP or JavaScript can take months. SASS and LESS CSS are merely extending CSS with a handful of natural features. You can be up and running in a couple of hours.

  8. jcDesigns says:

    Thanks Rhett for the comments. I just looked up LESS, and it is a Ruby gem. Is there a reason you went with that over Sass? Because like you said, the idea is very similar. I installed Ruby, then installed the haml gem to get Sass. I know there are other ways to do it without Ruby, but that just happened to be how I went about it (that am I am interested in learning some Ruby).

    Ok, I hadn’t thought that far ahead, but using a mixin for the CSS3 vendor prefixed stuff is great. Write it once, include easily after that.

    Are you a Ruby person? If so, can you point me in a direction of a tutorial where it starts from “I’m an idiot” to “Hey, I just got something running and uploaded to my site”? I’m looking for something to explain how to connect the ruby file to the html, and make it work.

  9. I have been interested in using Compass and Sass for several months, but never got the chance to dive into it fully. I wanted to try it on a large scale web project that I am working on, but my main concern was that the CSS developers that pick up the job after me wouldn’t understand the Sass syntax and would make a mess of things. I’m expecting the stylesheet to be 4000+ lines long, so I didn’t want the Sass compiler to break because someone didn’t indent the CSS consistently.

    A few months into the project, one of my co-workers introduced me to LESS. In this situation, I decided to use LESS because it’s syntax was like regular CSS and I could import the 500 lines of CSS that I had already written without reformatting anything.

    That being said, I plan to move to Sass and Compass after this project is finished. I think the LESS authors want to keep LESS simple for designers. I fancy myself as a power user though and it seems that Sass is the more feature rich of the two.

    I use Ruby with the Rails framework for database driven websites and PHP for sites that do not require a database. I started with the O’Reilly “Learning Rails” book and was able to get started without knowing much Ruby. Be warned though that the Rails framework is on a fast development cycle and not always backwards compatible. So if you’re using version 2.3 and reading a tutorial about version 2.1 the code may not work. Ruby on Rails is a fantastic combination though. I have also heard good things about Merb, which is a Rails competitor. Nice blog by the way.

  10. jcDesigns says:

    Thanks for the info. Just to let you know, Sass 3 is out now, and it has a new syntax called SCSS, which is written more like CSS than it is with the indenting syntax. Still has all the good stuff as the previous version, but I think the learning curve is easier now.

  11. [...] you have kept up with me, then hopefully you read my post on Sass 3. If not, well hopefully you are not out of the loop and have at least heard of it. This post is [...]

  12. [...] second one, which really meant a lot, was when Nathan Weizenbaum commented on my “Test driving Sass 3…a second look at Sass” article. He is the lead designer of Sass now, and when he posted, I felt that I had become a [...]

  13. [...] Test driving Sass 3…a second look at Sass [...]

Leave a Reply to jcDesigns