Skip to main content

Sass for WordPress Developers

By James Steinbach



Free JavaScript Book!

Write powerful, clean and maintainable JavaScript.

RRP $11.95

Sass for WordPress Developers

There are many benefits of Sass for WordPress developers. You’ve probably heard many arguments for using a pre-processor by now. CSS pre-processors provide the opportunity for better code organization by using partials and nesting styles. Pre-processors help developers style faster by writing mixins and functions. Pre-processors also allow us to write more maintainable, scalable code with logic and variables.

Convert a Stylesheet to Sass

The best way to start using Sass in WordPress development is to use a theme that has Sass files included. The Underscores theme is my favorite starting place for a new theme. However, if you’re starting with a theme that doesn’t have Sass files included, you’ll need to convert the existing stylesheet to Sass.

The good news is that if you’re using the .scss syntax (which I recommend), your existing CSS is all valid Sass. You can simply copy style.css to style.scss and that .scss file will compile properly.

Setting Up Partials

At this point, you’ve got a long .scss file with just as much code as your original CSS file. You can now use variables and mixins, but this still isn’t organized better yet. We can get some much-needed organization by breaking the long stylesheet up into smaller files. Copy each “section” of style.css to a separate .scss file in your Sass folder. Name this file after what it contains with an underscore prefix. For example, your styles relating to your navigation go to _navigation.scss.

Once you’ve moved code to a partial, you’ll need to import that partial in your main style.scss file. Essentially, you’ll copy all the navigation code to _navigation.scss and replace it in style.scss with an import command. Note: the file name in the import does not have the underscore or the extension.

@import ‘navigation’;

CSS is still cascades (earlier styles are overridden by later styles of the same specificity), so be sure to keep these @import statements in the order you need for your final output.

Refactor as Necessary

Once you’ve broken the long stylesheet into smaller partials (so you can find code more easily), you can work on refactoring those partials. This step helps make things easier to maintain, but I wouldn’t consider it essential. One way to refactor is to nest selectors. If you have several styles defined with in a certain parent selector, you’ll have this in your original stylesheet:

.header .logo {
.header .tagline {
.header .menu {

You can refactor those styles to make them easier to scan and edit by nesting the child selectors like this. The following block of Sass will compile to the same CSS we had above.

.header {
.logo {
.tagline {
.menu {

You can also refactor by replacing repeated prefixed properties with short mixins.

.menu a {
-webkit-transition: color 0.2s;
transition: color 0.2s;

A mixin can do the same thing. Note: I haven’t include the @mixin statement here: I recommend using the Bourbon or Compass mixin libraries for standard things like this.

.menu a {
@include transition(color 0.2s);

Further note: I actually don’t recommend using mixins for prefixing: AutoPrefixer is a much better solution, but that’s a different article.

Compile Your Sass for WordPress

Now that we’ve broken the big style.css file down: how do we put it back together?

Compiler Requirements

WordPress has a few unique requirements for the CSS output. This file needs to be named style.css, it must live in the theme root, and it needs a special block of WordPress comments at the top.

In addition those WordPress-specific considerations, I’d also add the following requirements for our compile process. It’s best to keep all the Sass files in a subdirectory (/sass/) so we can keep the theme root clean. We should also be able to compress CSS output for our deployed code.

GUI Compile Methods

If you prefer an app to compile your Sass, the following apps provide a GUI for selecting and watching folders of .scss files.

CLI Compile Methods

I don’t use those apps often: I prefer the command line. There are two tools to compile your Sass from the command line: Sass and Compass. You can find instructions for installing Sass and Compass as command line tools (Ruby gems): Sass / Compass.

Sass’s CLI provides the sass command for compiling a Sass input file to CSS output: sass style.scss:style.css. Of course, re-running that command every time you change something in your Sass partials isn’t ideal. You can add the --watch parameter and Sass will watch the .scss file (and the partials it imports) and compile every time it detects a change: sass --watch style.scss:style.css.

We can improve our compile method even more by using Compass instead of Sass. The biggest benefit of Compass is that it operates on a config.rb file. You can save your configuration options (expanded vs. compressed, input & output directories, etc) in a file, then tell Compass to watch and compile your Sass by running compass watch in the directory that contains config.rb.

Here’s how I use my Compass config.rb file:

  • It lives in /{theme-name}/sass/
  • It ouputs style.css up a level to the theme root: css_dir = '..'
  • The .scss files live in the /sass/ directory: sass_dir = ''
  • During development: output_style = :expanded
  • For deployment: output_style = :compressed

WordPress style.css Comments

As we noted above, WordPress requires some specific comments at the top of the theme stylesheet. We can control those in style.scss in our /sass/ directory. Since Compass will remove comments with output_style = :compressed, we’ll need to start the comment block with an exclamation mark (!) to preserve these comments.

Theme Name: Sassy Theme
Theme URI:
Author: James Steinbach
Author URI:
Description: From CSS to Sass Sample Theme Code

//import all your partials

Organize Your Partials

Now that we know how to turn a stylesheet into Sass and put it back together, let’s talk about how to organize your Sass partials. The first thing to keep in mind is that cascades still matter. Make sure to import your broadest styles first and your most specific styles last.

You can use folders to organize your partials. For a partial in a folder, your @import statement would include the directory name like this:

@import ‘base/variables’;
// imports _variables.scss from the /base/ directory

There are many ways to group your partials into folders. The “Sass Resources” list below contains some good philosophies for organizing partials. Here’s one example:

  • /base/ (variables, mixins, reset, typography)
  • /layout/ (grid, header, footer)
  • /vendors/ (plugins, vendors, etc)
  • /components/ (buttons, menus, forms, widgets)
  • /pages/ (home, landing page, portfolio) Sass Structure

Sass Resources

We’ve just scratched the surface of using Sass to build WordPress themes. If this is your first read on the topic, you might be wondering, “Where do I get more information?” The following lists provide more information on methods for using Sass for WordPress development. Some of their advice differs from this post: you can follow the path that works best for you.

Additional Sass Reading

If you have other resources to recommend or lessons to share, please post them in the comments!

James is a Senior Front-End Developer with almost 10 years total experience in freelance, contract, and agency work. He has spoken at conferences, including local WordPress meet-ups and the online WP Summit. James's favorite parts of web development include creating meaningful animations, presenting unique responsive design solutions, and pushing Sass’s limits to write powerful modular CSS. You can find out more about James at

New books out now!

Get practical advice to start your career in programming!

Master complex transitions, transformations and animations in CSS!

Latest Remote Jobs