I work in WordPress development and I've always been told by more seasoned WP devs to compile my theme SCSS into a separate style.css file, typically into a sub-directory like assets/css/style.css.

Today however I read an interesting article on SitePoint where they talk about compiling their SCSS directly into the style.css file in the theme root directory (ensuring cssnano preserves the opening block comment meta), removing the need to enqueue a separate CSS file.

Additionally, on the WordPress Codex page for Theme Development it reads:

In addition to CSS style information for your theme, style.css provides details about the Theme in the form of comments.

There is no mention in the entire codex page about needing to separate your styles into another CSS file and enqueuing it via functions.php.

My question: Are there any caveats to compiling all of my theme's SCSS into the style.css file in the theme root?

1 Answer 1


Your theme requires style.css to be present in the theme's root directory, with a comment header at the top containing information about he theme, like this:

Theme Name: Twenty Nineteen
Theme URI: https://wordpress.org/themes/twentynineteen/
Author: the WordPress team
Author URI: https://wordpress.org/
Description: Our 2019 default theme is designed to show off the power of the block editor. It features custom styles for all the default blocks, and is built so that what you see in the editor looks like what you'll see on your website. Twenty Nineteen is designed to be adaptable to a wide range of websites, whether you’re running a photo blog, launching a new business, or supporting a non-profit. Featuring ample whitespace and modern sans-serif headlines paired with classic serif body text, it's built to be beautiful on all screen sizes.
Requires at least: WordPress 4.9.6
Version: 1.4
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: twentynineteen
Tags: one-column, flexible-header, accessibility-ready, custom-colors, custom-menu, custom-logo, editor-style, featured-images, footer-widgets, rtl-language-support, sticky-post, threaded-comments, translation-ready

So the only thing you really need to consider is whether your build process strips out comments. If compiling your SCSS removes comments, the resulting stylesheet won't be valid for style.css, because it would be missing the header comment. If you want to compile to style.css, make sure you're either not removing comments, or have a process to insert the comment after compilation.

Anything other than that is really just a matter of opinion, and how you prefer to organise things.

  • 1
    Thanks @jacob-peattie! Fully understand the base style.css requirement and the block comment header, and I can rework my gulp tasks to accommodate it. I was just told (strictly!) to never include any CSS rules in the base style.css, "just because"... Thanks again for your answer; keen to hear if anyone else has any differing opinions!
    – Dan Walsh
    Commented Oct 9, 2019 at 9:52
  • 1
    The only 2 reasons I can think of that someone might say not to use style.css for styles. First is that relative URLs to images or fonts in the CSS might be neater if the stylesheet is stored somewhere else relative to the directories that contain those resources. Second is if you really wanted to emphasise separation of concerns. Arguably CSS styles and theme version/licensing information are two separate things that shouldn't be mixed. But that's really a matter of preference, and doesn't make much of a difference practically speaking. Commented Oct 9, 2019 at 14:41
  • Does the documentation specify if license comment style is (asterisk exclamation mark) is considered bad practice? Commented Feb 20, 2023 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.