Sass is a CSS preprocessor: a programming language of sorts that compiles to CSS stylesheets. Lots of front-end developers love it. I’m not 100% in love with it. I’m a CSS purist. But how does Sass matchup with WordPress? How can a WP theme or plugin developer incorporate Sass into their WordPress development?
I don’t like Sass, but you might
A disclaimer: I’m a purist. I want my CSS just so. Sass tends to overcomplicate the rendered output, in my opinion. And that’s without all the extra steps required to use it. Jacob Thornton, formerly a developer at Twitter, has lots to say about Less, a competitor to Sass, and its uses. What I like best is Jacob and his team’s style guide, specifically their opposition to nesting. Lots of devs love Sass/Less for its nesting abilities (among other things, of course). I say it’s a bell/whistle that can cause more harm than good.
But. I’m in the minority here. Lots of WordPress developers love Sass/Less so it’s worth discussing how the Sass WordPress matchup works. I keep calling it matchup. I just mean how to use the two elements together. But I digress.
How a Sass WordPress matchup works
WordPress has a very specific file structure. It has some flexibility, but not much. You have to make sure your Sass settings play nice with WP’s files and directories. I won’t write a long, step-by-step Sass WordPress tutorial here. Plenty of others have already done that (see Further Reading below). Instead, I’ll cover the basics. If you’re anything like, you may enjoy a general “here’s what we’re talking about” primer before diving into the code and tech specs.
Sass isn’t right for every use. There are plenty of cases in which using Sass would be a mistake. When it comes to WordPress, the main use case for Sass or Less is when you’re writing something from scratch—probably a theme, child theme, or plugin. The reason Sass should only be used in these cases is that it has a delicate workflow. Changes and additions must start in the Sass files, then run through the compiler, and finally be turned into generated (or compiled, duh) CSS files. If anyone edits the CSS files, the next time a change is made to the Sass/Less file, those CSS changes will be overwritten and lost. Therefore, if you’re editing a theme, plugin something else (which is generally a no-no anyway), Sass isn’t for you. Just skip it.
The best thing I can think of for using Sass and WordPress is splitting WordPress’ default styles into includes to help with organization & readability. Of course you can split your own theme/plugin styles into those includes as well. I don’t like nesting, so I won’t recommend that. So if that’s what you’re into then go ahead and move along. (Meghan Trainor anyone?)
In general, the Sass WordPress question is fine. Sass and Less have their uses. WordPress themes and plugins can certainly be among them. I don’t love it, but as noted, I’m not a CSS preprocessor fan anyway. As long as you play by WordPress’ rules and plan to avoid conflicts, you should be fine. Happy WordPress Sassing.