Four Reasons to Fall in Love with Sass for WordPress (if You Haven’t Already)

Four hearts

I presented at WordCamp Seattle over the weekend, about a tool that has made my frontend development work way easier: Sass, the CSS preprocessor. It was really fun, and I’m still on a Sass kick, so this week I’m singing Sass’s praises to anyone out there who still feels nervous about diving in and learning what Sass is all about.

What is Sass, Again?

If you like analogies: Sass is to CSS as PHP is to HTML.

Sass is a CSS preprocessor: a more flexible and dynamic way to write style rules, which ultimately turn into the static CSS your browser understands. If you did well on the analogies part of your SATs: Sass is to CSS as PHP is to HTML.

If you’d like more of a conceptual introduction to Sass, I’ve written about Sass and WordPress before, in a previous WPShout article and also an article for Torque Magazine, as well as on the blog of our consultancy, Press Up. I’ve also got some freshly delivered slides on the subject.

When you’ve read up a bit, come back and I’ll do my best to convince you that Sass is wonderful and something you can use right away!

Follow Along with Our Demo Plugin

Items number two through four below are all technical things that Sass makes possible. This article gives code excerpts for each demo, and the full code for all three demos is in a custom plugin, which you’re free to download or browse on GitHub and play around with as much as you like. The plugin contains:

  1. The Sass markup for the three examples.
  2. The CSS the Sass compiles to.
  3. A text file with the HTML markup used in the three examples.
  4. A very basic PHP file to register the plugin and enqueue its CSS stylesheet.

Let’s get going!

1. Compiling Sass Doesn’t Have to Be Scary

Sass has good GUI compilers!

The thing that initially kept me off Sass was the apparent difficulty of compiling it. “Compiling” Sass means having a computer turn your Sass styles into the CSS a browser understands. It’s very important, since without it a Sass file can’t do anything.

The default way you compile Sass is:

  1. Via Ruby.
  2. In the command line.

Those are two things I barely understand. I’d like to learn them better in the future, but for now here’s the good news: Sass has good GUI compilers!

In other words, there’s a little thing you can download onto your desktop that handles compiling Sass with just a couple mouse clicks. I use Koala, and look how easy it is:

Subsequent compiles are even easier, since Koala will just “auto-compile” in the background every time you save the Sass file. So if you’ve been kept out of Sass by fear of command-line Ruby, no longer!

2. Dynamically Computed Colors

Quick, what’s the HTML hex for the color that’s 30% lighter than blue? I don’t know, and if you’re tired of calculating color relationships, why not let Sass do it?

Hover or focus the buttons below. You’ll see that they all lighten to a uniformly lighter version of themselves.

I never had to calculate those lighter colors—I’m doing that in Sass, as follows:

@mixin lighten-on-hover($color: #00f) {
	&:hover, &:visited:hover, &:focus, &:visited:focus {
		$lightened: lighten($color, 30%);
		color: $lightened;
		border: 1px $lightened solid;

So I can set these buttons to any color, and I know that I can make them all lighten uniformly—all computed automatically by Sass. Pretty cool, right?

3. Automatic Text Contrasts

Sometimes you’re changing theme colors all around, and you do something silly, like put black text on a black background. That’s just what I did with the red block below: I set the colors in my Sass file to put red text on a red background.

I’m okay
I’m okay too!

Normally, this would mean invisible text—but Sass automatically lightened the text to pink. Here’s how:

@function ensureTextContrast($text-color, $background-color) {
	/* Getting value for contrast */
	$diff: lightness($text-color) - lightness($background-color);

	/* If high enough contrast, @return original color */
	@if abs($diff) > 15% {
		@return $text-color;

	/* Dark background; lighten */
	@if lightness($background-color) < lightness(#aaaaaa) {
		@return lighten($text-color, 30%);

	/* Light background; darken */
	@else {
		@return darken($text-color, 30%);

With this function in place, I don’t have to worry about changing my color variables theme-wide—Sass can catch any font-background combinations that are too hard to see.

4. Think in Pixels, Code in rems

The rem unit is a great way to size a theme’s fonts such that they all change together. Doing it this way is good for accessibility, among other things. But rems aren’t always very intuitive: sometimes, you’d like to think about your font sizes in pixels—the font sizes you’ll actually see if your browser’s font size is the default, as most people’s are.

With Sass, you don’t have to choose. Here’s how:

@mixin rpx($px: 16, $base: $base-font-size) {
  font-size: $px + px;
  font-size: ($px / unitless($base)) + rem;

This mixin is very simple. It takes pixel values, as follows:

.demo-p {
	@include rpx(16);

.demo-small {
	@include rpx(10);

And it gives those same values back in rems (and pixels, for the one dumb old browser that doesn’t understand rems and needs a fallback). You get easy access to the pixel sizes you wanted, plus the accessibility of rems, and a browser fallback, all at once. The result:

I’m normal-sized, rems-based, and have a px fallback!

I’m small, rems-based, and have a px fallback!

Loving Sass Yet?

Of all the technical tools I’ve taken on as a developer, Sass is one of the most useful, and has one of the gentlest learning curves. If you do any amount of front-end development, I’d strongly suggest checking it out.

What do you love about Sass? Or what’s still weird and confusing about it? We’d love to hear from you!

Image credit: Procsilas Moscas