Introducing sassy_s

I’ve been using Underscores (aka _s) for all my base theme needs since pretty much the day it came out. And I’ve been using Sass for more and more projects — so, inevitably, I started smooshing the two together.

Sass actually makes it really easy to do this, at least if you use the default .scss format. All valid css files are also scss files; you can just take your css file, change the file extension to .scss, and start throwing around variables and functions and all that Sassy stuff. But while it’s easy to get a project rolling that way, it leaves something to be desired organization-wise.

One of the very cool things about Sass is that it assumes that you’ll work with multiple files (partials, in Sass-speak) and compile them into one at the end; renaming the big stylesheet and working from there like I’d been doing still left me searching through a lot of lines of code to find what I needed. Ideally, I’d have a file for menu styles, a file for media styles, and so on. Even better, I’d be able to drop in a file of my own favorite mix-ins without recreating them for each project. I always set up my color schemes first thing, my base fonts and line heights, set up clearfixes and assistive text the way I want them, set up common styles for borders and boxes and the like; the values change, but what I’m styling has a lot of the same structure from project to project. (That one’s not included in the repo, but I’d love to hear about other people’s favorites.)

So to make more lazy level up my own practice, I finally took the time to make all this into a properly organized repo. Y’all can grab it here:

A couple of notes:

  • sassy_s is just a refactoring of the stylesheet — not a complete starter theme. It’s designed to work with a copy of _s, not replace it.
  • I’ve provided links to a couple of beginning Sass tutorials, and a couple of inline examples, but there are lots of great resources out there for installing and using Sass. If you have Sass questions, they’re the place to start.
  • The sass --watch command will overwrite your style.css with every change. Start with a fresh copy of Underscores and copy over your style.css header first. Don’t add this to a theme you’ve already made (unless you’ve got it under version control!)
  • If you’ve heard that you can’t use Sass if your end-users don’t run Ruby on their servers, fear not! In almost all cases, you should be running Ruby and Sass on your development machine, then exporting your Sass to a normal CSS file. It’ll run just as well as any other theme.

15 thoughts on “Introducing sassy_s

    • I won’t pretend I had a super-rigorous process. I heard of both at around the same time, played with them a bit, and picked up Sass because I wanted Compass — a little ironic since I’m not using Compass for this project, although it could still happen at some point in the future. Chris Coyier has a good article on some of the key differences, but for me it mostly comes down to “I liked the tool I got used to enough to stick with it”.

  1. Thanks for the tip Amy, since SASS is my preprocessing weapon of choice, and I’ve been wanting to try out _s, I’m going to try it out on my next project!

  2. As a developer, I’m always looking to better my productivity on projects. I was pointed to your post and it’s a great one at that.

    Now I get projects that call for a framework such as Genesis. I also get those projects that call for a custom theme that just makes it easier to use a starter theme. For years, I’ve used Starkers, but I’m doing my research in finding others and always had my eye on _s. Now _s does have smallmenu.js to accomodate the menu on smaller screens, but that’s the only thing that’s “out-of-the-box” for responsive design, correct?

    I’m just getting more and more projects that always want the responsive design, so I’m looking at Foundation and Bootstrap as well to maybe give me that jump start. I’m curious how you, as a fan of _s would handle the mobile devices.


    • Hi Jason, nice to meet you and thanks for the thoughtful questions.

      Almost all of my projects are responsive these days, so wrestling with the different options is definitely a concern I’m all too familiar with. On the other hand, I’ve really come to dislike the big frameworks like Foundation and Bootstrap; I’ve gone through several rounds of trying them out, loving what they can do at a quick prototyping level, and then a few months later cursing at them as I rip out thousands of lines of unused CSS & JS that I’m not using anyway… (the current theme on this blog started as a Bootstrap project, as a matter of fact).

      Instead, I’ve been moving more and more towards putting together my own set of pieces I trust — so, using Susy for responsive grids, (which depends on Compass, not covered in this post, but really cool if you’re into Sass), fitvids if a site will use video, and so on, for only the puzzle pieces I actually need on that specific project, rather than depending on any one monolithic framework.

      _s is actually incredibly good for this way of working; it doesn’t include very much of it out of the box, but it doesn’t do anything to hinder you either. (I’ve gotten annoyed in the past at other starter themes that assume that every project will use the same grid system, or the same UI elements, or… you get the picture.)

      • You sound very much like me in many respects. I’d much rather spend the time in putting things into a project than spend that same amount of time taking things out.

        I’m just getting into Sass, which is why I landed on your post. I will take a look at Susy for sure, even though I have no clue what it is right now :).

        Since I’ve been using Starkers for years and now starting to level up some aspects of my “game,” I’m just seeing some of the many options and trying to come up with what works for most of my clients and projects. Thanks again for the reply, as well as confirmation that I seem to be going down the correct path.

        • Good luck with it all! If you’re used to Starkers, you’ll find _s to be a fairly similar approach — the main difference I find is that Starkers uses a non-standard and IMO unnecessary approach to templates when WordPress handles all that automatically.

          As for Sass, I usually advise people to start fairly small — get into using some variables, extending some classes for the bits you find yourself repeating over and over, and build from there. There’s a ton of stuff out there right now, and it can feel as overwhelming as learning an entirely new system. Just like with building a theme, I prefer to take the parts I need.

          • Thanks for the advice. I’m going to be using Sass on my next project which starts this week, so we’ll see how that goes :).

            Being a developer first and foremost, I’m looking forward to the variables rather than having to remember the hex values over and over again.

    • Do you mean the linked on the Compass home page? If so, I’ve never used it. At its heart, Compass is just a bunch of Sass mix-ins; everything works perfectly from the command line. (There are also extensions/snippet collections/etc. for a number of code editors, but that’s such a matter of individual preferences that I’ll leave you to your own research on that one.)

      • Oh ok, yes I see that now. I didn’t realize that Compass was a command line tool, I thought it was just an Application. (Still learning as a Sass newb)

        I see that in some tutorials out there people create compass projects, but in using WordPress as the main part of the project, are we still creating a compass project? Do you have any tutorials using Compass with WordPress?

Comments are closed.