Sass and WordPress: A Love Story

WordPress and Sass

Today we’re discussing a key tool in the WPShout redesign: Syntactically Awesome Stylesheets, or Sass.

We launched a redesigned WPShout a few weeks ago. We’re super-happy with the redesign, and the cleaner PHP backend is already opening up a lot of things we want to do with the site. (For example, we’re starting to organize our content into courses, which has been a goal of ours for quite a while.)

The redesign was also a great opportunity to practice what we preach as WordPress developers: building beautiful, performant, technically sound, easy-to-use WordPress sites. And we got to choose our own tools, because we were the clients! Today we’re discussing one tool that turned out to be indispensable for rebuilding the WPShout theme: Syntactically Awesome Stylesheets, or Sass. Let’s look at Sass and WordPress, and see why they might just be a match made in heaven.

Why Do We Need CSS Preprocessors?

Sass is a CSS preprocessor: a programming language that compiles to (spits out) CSS stylesheets. Like any CSS preprocessor, Sass exists to let you write styling rules in a manner that is:

  1. DRY: “don’t repeat yourself,” meaning less copy-pasting and blind repetition.
  2. Dynamic: capable of interpreting variables.

What Does Non-DRY CSS Look Like?

Let’s look at one example of “non-DRY CSS,” and why it might be an issue:

.nav {
	font-family: "Georgia", serif;
}

.nav .nav-element {
	display: inline-block;
}

.nav .nav-element .nav-dropdown {
	background: #eee;
}

Pure CSS is flat: there’s no way to indicate structure, except inside an individual styling rule. In a highly structured stylesheet, this means a lot of repeating of “.nav,” “.nav-element,” and so forth.

The code repeats itself, so one change breaks it in multiple places.

Now imagine, what happens if we rename “.nav” to “.nav-menu“—or get rid of .nav altogether? We’re going to have to manually rewrite every styling rule we wrote that depended on .nav. In other words: The code repeats itself, so one change breaks it in multiple places.

CSS is Static; What’s Wrong With That?

Let’s look at an example:

.small-rounded-square {
	height: 16px;
	width: 16px;
	border: 1px #333 solid;
	border-radius: 1px;
}

.medium-rounded-square {
	height: 32px;
	width: 32px;
	border: 2px #333 solid;
	border-radius: 2px;
}

.large-rounded-square {
	height: 48px;
	width: 48px;
	border: 3px #333 solid;
	border-radius: 3px;
}

.xl-rounded-square {
	height: 64px;
	width: 64px;
	border: 4px #333 solid;
	border-radius: 4px;
}

See the problem? These are all squares, meaning their width equals their height automatically. Moreover, they’ve all got a dark gray border equal to 1/16 of their width. And yet you have to write that all out by hand—giving us more non-DRY code that will be difficult to maintain and change.

How Sass Helps

Let’s look at the two code snippets above, done the Sass way:

.nav {
	font-family: "Georgia", serif;
	
	.nav-element {
		display: inline-block;

		.nav-dropdown {
			background: #eee;
		}
	}
}

See? Sass has nesting!

Notice that this allows us to name each element only once. If we change (or even remove) .nav in our HTML markup, we only have to change one thing in our Sass to reflect that change, instead of potentially dozens in vanilla CSS. The code above compiles to (spits out) exactly the CSS code in the first example—but you’ll only ever need to write and maintain the simpler version.

When and whether to nest your CSS rules is a subject of debate, but the point is that with Sass you can actually do it properly.

@mixin square($side: 16px) {
	width: $side;
	height: $side;
	border: $side/16 #333 solid;
	border-radius: $side/16;
}

.small-rounded-square {
	@include square;
}

.medium-rounded-square {
	@include square(32px);	
}

.large-rounded-square {
	@include square(48px);
}

.xl-rounded-square {
	@include square(64px);
}

Here, we define a mixin called “square” that captures the important shared properties of the squares we’re working with. Our mixin accepts a variable value—$side, set to a default of 16px if nothing’s passed in)—just as a PHP or JavaScript function might.

Then, when we go to define our actual squares, we simply @include square—like calling a function in PHP—giving it a custom value for $side if we don’t want it to be 16px.

A huge advantage of Sass is that you can standardize and centralize your elements’ properties.

The huge advantage of this way of doing things is that you can standardize and centralize the properties of your square elements. Want to get rid of the dark-gray borders across the site, or maybe give the squares a light gray background? You only have to go one place to do it: the square mixin definition. All your square elements, of all sizes, will inherit the styles automagically.

Pretty Cool, Right?

Starting to see the promise of Sass? I’ll tell you seriously that I don’t know how I would have done the new WPShout theme (or another recent large project I completed a few months ago) without it. Once you’re able to start nesting elements, referring to variables (font-size: $base-font-size), and dropping in repeatable bits of code, it’s just about impossible to consider going back.

How Sass and WordPress Interact

In WordPress, there are only a few times when you’re staring at a giant, blank stylesheet—which is where Sass really shines.

Working in a WordPress project is a bit different than working on, say, a greenfield web application powered by a JavaScript framework. The WordPress environment is set up in a pretty specific way, and there are only a few times when you’ve got a giant, blank stylesheet staring you in the face—which is where Sass really shines.

Drawbacks of Sass

I’ll also mention three potential drawbacks of Sass, in order of importance:

  1. Sass means one more layer of abstraction preventing a beginner user from understanding what you’re doing. Compiled stylesheets are not necessarily as readable as hand-written ones—and can be completely opaque if you don’t think about the CSS your Sass is spitting out—and even readable CSS stylesheets don’t always encode the underlying logics that guided the original Sass programmer.
  2. Sass creates the possibility of versioning conflicts: future users of your software can make changes either to your CSS stylesheets or your Sass partials, and can potentially end up overwriting one another in the process.
  3. Writing Sass and getting it to compile is significantly more complicated, and marginally slower, than simply writing straight to a CSS file.

When to Use Sass as a WordPress Developer

So Sass isn’t cost-free. When to use it? Based on my experience with Sass and WordPress, I’d say I’d endorse the following very rough rules of thumb:

You should definitely use Sass if you’re building a theme from scratch. It’ll save you dozens of hours, and the final product will be so much better.

You should probably use Sass if you’re building a child theme. Really, it depends on how extensive the CSS modifications you’re making: if you’re going to turn a stock theme like Twentyfifteen into something totally different, Sass is a no-brainer; but for a couple of stray recolorings and font changes I’d say it can be overkill.

I’m not sure you should use Sass if you’re building a plugin or modifying an existing theme. An existing theme is pretty much the tangle of wires and silly string that it is; adding Sass on top of everything might be a bit like dumping a brand-new file cabinet on top of a trash heap, on the theory that it’ll “organize everything.” As for plugins, the power of Sass makes sense in some cases (say, for a landing page plugin with a lot of design options), but may again be overkill for others.

Getting Started in Sass

There’s no way this post can teach you everything—or even very much—about how to use Sass. But here are some resources:

Compilers

The hardest part about Sass is getting it to compile. This usually requires someone who understands command-line Ruby, as well as a server that can run Ruby. That’s the kind of technical hurdle that often keeps me from even considering cool tech tools like Sass.

The biggest single Sass breakthrough for me has been finding Koala.

That’s why the biggest single Sass breakthrough for me has been finding Koala, a GUI-based desktop app that automatically compiles Sass to CSS for you. It’s dead-simple on Windows, and claims to work on Mac and Linux as well. The tutorials below also list a number of other compilers, which I expect work but haven’t tried.

Tutorials

WPShout Theme Sass Files

In a slightly nerve-wracking gesture of transparency, I’m giving you all the Sass that I used to build the new WPShout theme. Here’s a zip file: wpshout_sass.zip. (If you weren’t aware, you can generally view a WordPress site’s compiled CSS stylesheet at //site.ext/wp-content/themes/theme-name/style.css, as here.) You shouldn’t be able to actually build WPShovt.biz with it, since you don’t have access to the PHP that makes up the theme itself; but if you’re really curious about Sass itself I think there’s quite a bit of embedded Sass knowledge and learning in there, and a good case study of how Sass and WordPress intertwine.

Get Sassy With It!

I presume that pun’s been used before.

I presume that pun’s been used before. I actually think I prefer programming languages with blander names, since the puns are more difficult and hence more rewarding.

At any rate, I hope this post has got you excited about the power of Sass, and given you some tools to explore it for yourself! It’ll do an awful lot for your power as a front-end programmer, so if you haven’t yet given it a look, please don’t delay.

What do you think about Sass, Sass and WordPress, and CSS preprocessors in general? We’d love to hear from you in the comments below!


1 Response

Pingbacks