David Walsh on Redesigning with Sass

The following post is by David Walsh. David is a web developer from my own hometown of Madison, Wisconsin and currently working for Mozilla.

David recently redesigned his blog and is having a series of guests write posts for his site. We decided to do it crossover style: he writes an article for CSS-Tricks and I'll write an article for the David Walsh blog. He used Sass in his redesign and his article below is about that experience. I've been using it for closer to a year, so my post on his site is about that experience.

Creating any website without using a CSS preprocessor seems a horrible decision. Even if only to be able to quickly modify a few colors or element dimensions, or even just to easily merge and compress CSS files, CSS preprocessors are becoming essential. For my recent redesign of the David Walsh Blog, I decided now was the time to dive face first into CSS preprocessors. Here are a few thoughts about my experience, and hopefully you pick up a few tips along the way.

Deciding to be Sassy

There's not much a decision to be made about whether or not to use a tool like Sass or LESS, the questions is more of which should be used. In the end, I chose Sass because:

my experiences with LESS have been ... less than appealing; the tool seems ... less maintained

a utility like Compass, a collection of mixins with an updater, is invaluable

When you author a blog like David Walsh Blog or CSS-Tricks, learning a new CSS utility also presents the perfect opportunity to write about another useful topic. Using Sass on this project was obviously the best choice.

:hover, :active, :focus Styles

I used these mixins quite a bit throughout my code. A few of my snippets mimic functionality provided by Compass, but I like seeing the specific styles provided by mixins.

Mistakes, Mistakes

As with using any tool for the first time, I made quite a few mistakes. Mistakes are healthy though - you learn from them and write about them so others don't take those same missteps. Mistakes I made include:

Nesting == Bloat: The biggest mistake I made with Sass, by far, was nesting styles when they didn't need to be. At the time of launch, my main CSS file was a vomit-inducing 59k! I'm still working toward reducing the size of my styles, and it's a much more difficult task now that the site has launched because of...

...Specificity Clashes: Because of my issue with nesting styles when I didn't need to, I ran into a bunch of specificity clashes, bloating my CSS file even further. When it got to the screen size media query CSS, I was needing to mark everything as !important. That's an incredible amount of CSS bloat and hassle because of improperly using SASS selector nesting.

Sprite Generation... Too Late: One of the big reasons I chose SASS was because I knew SASS managed sprite generation. What a time-saver, right? Well, only as long as you knew how to format them in the first place. My problem was that I created my CSS with normal background-image declarations, without paying attention to SASS' desired format. I went to create my sprites after knowing the correct format and said "WTF FML". In the end, I created my own sprites because I didn't write my SASS correctly in the first place. Very annoying mistake.

Duplicating Compass-provided Helpers: I don't need to cite them... I'm more than certain I duplicated functionality provided by Compass. I'll likely pay for it later if I don't update my code and stay aware of browser capabilities.

Tips and Last Impressions

I want to leave everyone with a few tips for getting started with SASS, and share a few last impressions of Sass development:

You can nest media queries for selectors but I prefer creating a separate file for mobile / media query-specific styles; it allows me to see the entire set of mobile styles in one glance. The same could be said for my print styles.

Utilize CSS animations as best you can -- they can save you a load of JavaScript code down the road.

In the end, I'm incredibly happy with my decision to use Sass as my CSS preprocessor. The documentation is helpful, you can get up and running in a few minutes, and Compass is an invaluable tool in so many ways. My only problems with SASS were self-inflicted, and will be easily avoidable the next time around. Give Sass a chance for your next website or redesign - its usefulness is immeasurable and will pay off for the duration of your project.

Prefixr has proven to be useful to me, but yeah, if you just use a preprocessor like SASS or LESS, you can just make a few mixins; prefixr isn’t necessarily needed, unless you are choosing not to use these. You don’t even need to rewrite the mixins either (the joy of copy/paste).

Great stuff. One challenge I’m still facing is working with a team / clients that may need to maintain the CSS afterwards as well. Still haven’t had the chance to commit a project to a 100% SASS solution.

David… Looked at your new blog and read Chris’ article then tried to leave you a comment – and your link doesn’t work. Tried to leave a bug report – but not going to register with git just to tell you of a bug you may find out about eventually. So, perhaps you’ll view these comments.

like the new skin to your site – one thing I’ve noticed. When viewed in narrow size (ie mobile) this post (Chris’) in particular shows only the title for quite a long scroll. ?possibly a media query to decrease heading tag font size might look nice? Just a thought.

With the hoverActiveFocus mixin, you’ll end up with a lot of code bloat if you’re need multiple rules, as SASS doesn’t yet group equivalent selectors. Instead, you just try replacing the rule statement with an @content statement. Learn More

Hmmm. This emperor does have clothes, but they are pretty shabby raiments with respect to integration

For example:
(1) the world’s most useful debug feature Firebug doesn’t know anything about SCSS file numbers (… I know … there are some kludgy plugins that help a bit etc etc) making debugging css with firebug virtually useless
(2) almost all of the universe’s best IDE’s have pretty good code coloring and code completion for css, but appear to know zilch about SCSS or LESS (sure … early days … plugins coming blah blah)
(3) preprocessors for css, hmm. perhaps javascript pre-compilers next, what a mess.

True that, my mayor culprit with using CSS Preprocessors as well. It almost turned me away in the beginning, but after a while it’s not so bad. I prettify the compiled CSS and paste it into the browser when I’m debugging. From there it’s easy(er) to find the corresponding row in my LESS/SASS.
Not entirely true! WebStorm have quite decent support and more is coming. Pair that with CodeKit and you have a pretty sweet setup!
Hopefully Source Maps will make it into CSS as well (we have them in JS – linking the minified/obfuscated file with the source), then all this issues will go away.

If you’re too lazy to do this, then you’re going to have a hard time with Sass… otherwise it will ease your life tremendously (of course, in the end it’s up to you, but at least don’t just reinforce clichés)

However I have two notes about your article:
I think that the snippet “Vendor Prefixing” is a bit over the top. Nowadays only very, very few properties need the whole slew of prefixes anymore. Since Firefox doesn’t need them for animations, transitions and transformations and IE10 uses almost everything unprefixed (and WebKit will surely follow soon), there is no need for such an enormous snippet in my eyes.

And since you mention the embedding of media queries: Don’t do (or suggest) that, because that would be a true reason for code bloat. Imagine if you nest every the media query for every property/element directly beneath it. Attaching all the media queries together at the end of the CSS is still the best way, until SASS automates that for us.

You don’t really expect everyone of your visitors to have the latest version do you?
Sure you could have a separate stylesheet for each browser and version, but that doesn’t seem any cleaner to me – au contraire…

SASS wont be able to group media queries together at the end of the CSS files as this will play havoc with the specificity of the selectors.

As Chris Coyer pointed out in a recent episode of Shop Talk Show, GZIPing your files will deal with all the repetition caused by having embedded media queries. Its also better in terms of code organisation as you can see all the styling for one element, regardless of the media query.

I have used Sass for a couple of projects and my biggest disappointment is that nested selectors use the descendant combinator (E F) instead of the child combinator (E > F).
I rarely use descendant combinators so I end up using “& > F” everywhere.

About 8 months ago I considered SASS, saw the word “ruby” then went with LESS and WinLess. That was probably a silly decision. One thing that always bothered me with LESS is how slow it was, in combination with WinLess, to build a .css file.

LESS development had been dormant for months (stuck at v1.3.0) and the github folks with 100+ issues were getting restless and talking about spinning it off with the developer’s blessing. I eventually jumped on the SASS/Compass train, and it’s better. LESS was actually just updated yesterday (Oct 18) on github, but I ain’t going back. On a PC, you can use the command line to auto-build your files.

What this does is allow you to base64 encode your images directly in the stylesheet instead of referencing files on the server. Saves in downloads, helps your Yslow/Page Speed scores (if you’re into that sorta thing), and acts as a nice way to cache bust your images, since you’re not actually serving any real file-based images.

If you use this technique, it will bloat your CSS something awful. Gzipping won’t really compress the Base64 stuff, so be sure to optimize your images before “inlining” them. Finally, if you care about IE7 (as many sites still have to cater to this demographic), you’ll have to feed the real image file to it as it doesn’t understand Base64. Something like:

Compass has tons of CSS3 helpers that you just have to import and then to use you do

@include border-radius(5px, 5px);

and it outputs all of the vendor prefixes. They also have other helpers built in like vertical rhythm to keep your font looking consistent. I know Compass also has a built in CSS Grid framework but I recently used Susy which is created by Eric Meyer and is a responsive grid framework I’ve loved using it and felt it was very easy to pickup on.

I’ve used both less and sass before. I think currently sass has more options but less is not that bad. I know it compiles for me quickly and I found learning less to be easier mainly because their documentation was better. I hope someone picks up the torch for less soon and continues the work but its something that can still be used. People have been bashing on it a lot lately and almost seems like its the in thing to do.

As for an earlier comment about only saving a few seconds when compared to css thats really not true. You save minutes which turn into hours down the road. Ever since I made the switch my workflow has increased greatly.

Heya, I’m still relatively new to SASS so I might be missing something here but was wondering why you are use mixin for clearfix rather than extend?

In the output, mixin basically repeats the clearfix code on the class you’re using it on whereas extend just adds the class to the code; resulting in less “bloat”. Also the clearfix code isn’t likely to change.

I’ve a query in css file edit, after making sass file, it compile css file, If I edit in css file in middle than again start work on sass file, now it will overwrite my edits in css, is there any way to ignore this.

Mufaddal, if you’re using something to automatically compile your SASS to CSS, such as Scout or a “compass watch” .bat file, then, NO, there’s no way to override the overwrite of your .CSS.

It seems you’re thinking of SASS/CSS like they should be synchronized forward and backward. The writing is only one way: SASS to CSS. But that’s the point of using SASS. You shouldn’t be diving into your raw .CSS file ever again–You should only be editing your .SASS file(s) henceforth.

Now, if you must have this disabled, then you’ll have to turn off whatever is polling .SASS file changes, and then run the compiler manually.

But just know, by doing this you can open yourself up to inconsistencies.

I am thinking “_partials” and then just use plain css – cause css is also valid scss. So all your additional css will be imported to the compiled main css. Give “partials” a read and it might be a way to go for your needs.

I know my comment is running late, but maybe helpful for the gentle reader and common stumble uponer.

This comment thread is closed. If you have important information to share, please contact us.

We have a pretty good* newsletter.

Email Address

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress, hosted by Media Temple, and the assets are served by MaxCDN. The fonts are Source Sans Pro and Source Code Pro. It is made possible through sponsorships from products and services we like.