Sass Rocks! Over Complicating Your CSS Doesn’t

Sass Rocks! Over Complicating Your CSS Doesn’t

Unless you are careful of course

So I’m in the middle of redesigning/rebuilding my main site, as you would know if you are keeping up with me here, and I am using Sass (SCSS syntax). I love it so far. There is a lot you can do to save you time during the build. There is also the “This new crap I’m using is awesome! I’m going to do this and this and this…”, which can get you in trouble. What kind of trouble you ask? The kind that over complicates your CSS of course. Stop talking and read please! Jeez, I’ll tell you how you can easily do that.

Think before you leap

A day after starting my build using this awesome technology, and no it isn’t new, but it is still fairly new to me. Syntactically Awesome Stylesheets has some cool features that you immediately want to dive into. Variables are the easiest, and it is kind of hard to abuse those. Mixins though, that is where I got into trouble. A good example, which you might have seen in my last post is a mixin I was using for ‘font’. Seemed like a great idea at the time! Let’s shorten that CSS so that I only have to type in the properties that will feed the mixin. What could be wrong with that? Well, technically nothing, but it also wasn’t helping me and I was just adding to the confusion with a completely stupid mixin (at least in this case). Here is what I am talking about:

@mixin font ($size, $weight, $family){
  font: {
    size: $size;
    weight: $weight;
    family: $family;
  }
}

To use that mixin, I then type out this SCSS:

.myClass {
@include font(18px, "bold", "Arial,Helvetica,sans-serif");
}

What is wrong with that? Well, let’s actually write out the CSS for it:

.myClass {
font: bold 18px Arial,Helvetica,sans-serif;
}

It’s actually shorter to write the CSS out rather than using the Sass mixin for it. That was my problem. And not just there. I had a few others with the same exact problem. How did I fix it? I sat there staring at the small amount of CSS I had and actually thought out everything. Where is Sass going to save me time, and where am I being stupid? So I thought about it, and rewrote the mixin. I changed it to have a defualt family since most of the time I am going to be using Arial anyway. The rare occasions where I won’t is where that variable will come in handy.

@mixin font ($size, $weight, $family: "Arial,Helvetica,sans-serif"){
  font: {
    family: #{$family};
    size: $size;
    weight: #{$weight};
  }
}

Now I don’t have to type in the family every time because that is my default. Why be repetitive? That is the beauty of using this. I then wrote this mixin for using a sprite over and over again:

@mixin sprite($left, $top) {
    background:  url(../images/iconSprite.png) no-repeat $left $top;
}

Now I just have to write “@include sprite(0, 0)” to get the sprite call’s position. This to me is being smart. Mixins should be used to reduce the amount of CSS you have to write later. Using Compass’ ‘@import’ to use some of the CSS3 stuff like border-radius and box-shadow was a good call too. When you use that and Sass together, it only takes one line to output the necessary 5 lines for browser pre-fixes. Brilliant! That is the kind of thing I needed to think about. I don’t want to use Sass just because it is cool, I want to use it the way it should be used – making dev time faster, and very easy to read/use stylesheets.

Just because you can doesn’t mean you should

This is my main point, and can be applied to any new tech we find or use in our development process. I imagine somewhere there are some people that used every dam CSS3 trick they could because they could, and because it was the new thing. You know, an element with box-shadow, text-shadow, border-radius, gradients, transitions…you name it, all on one thing. Why? For the look at what I did factor. I want to avoid that with my use of Sass. This build might take me longer than normal, but I want to make sure I’m not doing anything stupid, so I’m slowing down and thinking about what I am trying to do first. Where am I going to be calling the same thing over and over, and where will it matter?

I know that sounds silly, because shouldn’t we be doing that anyway? Yes. But how many times have you designed and sliced up a psd file, know exactly what divs/elements you need and just blaze ahead? I do most of the time. We just start typing away and plugging in everything – header div here, nav there, sidebar over there, footer here…need a ul for the nav and one for the footer, bunch of li’s and links. A lot of it takes no thought at all. You are done before you know it. While I am doing the layout like that no problem, the CSS is taking longer and I think it will help in the long-run. By slowing down and actually thinking about where a mixin would actually help, it’s helping me by thinking more clearly on my CSS.

I am hoping that by documenting what I am doing using Sass I will help you developers that are new to it, because honestly it is very hard to find information out there that is geared towards the newbie. Most of what I have found is written differently than what I am using (because they are using the original Sass syntax, where I am using its new one – SCSS) and written as if you are already familiar with it.

Again if you have any tips or pointers, please leave a comment and let me know. If you are just starting to use Sass/SCSS and want a good place to go to read up on it, check out Derek Perez’s blog. Tool around there and you will find some good info. I’d recommend following him on twitter as well, because he’ll tweet some good stuff. He is also very helpful if you have questions.

Coupon Code: webmachine

Tags: ,

One Response to “Sass Rocks! Over Complicating Your CSS Doesn’t”

  1. gripmedia says:

    While initially it may seem that SASS can complicates things, it doesn’t on large scale deployments. Having the ability to have functions in CSS opens up a huge new world of ease and customization. Would I use SASS for a small static website? Probably not. But for web application and large database driven sites, it’s a wonderful thing.

    And to have the ability to change a color in one line of code and it propagates through the entire design is a godsend, rather than having to find and replace the color in dozens of classes and declarations.

    Thanks for your article!

Leave a Reply to gripmedia