Mythic and ITCSS

Screenshot of the Atom text editor showing example SCSS code from the Mythic WordPress theme.

There are two systems that the Mythic starter theme uses to corral unmanageable CSS. I’ve already written a post on the use of BEM, a naming method for keeping your classes in check.

The second system is file-organizational technique named ITCSS (Inverted Triangle CSS).

The idea behind ITCSS is to organize your code in a manner of least-specific to most-specific. In modern design, that means organizing all of your stylesheets in a way that keeps you from having to write highly-specific selectors to overrule rules in previous stylesheets.

Mythic ships with this organizational structure already in place. We do deviate just a small bit from the original system to match up with WordPress theming.

What does ITCSS look like?

Here’s what the directory tree looks like in Mythic:


The blocks and customize-controls folders are not native to ITCSS. We use those for some WP-specific styles.

Theoretically, blocks could live under components, which is a change I might make some day in the future. For now, they have their own folder while the Gutenberg editor continues to evolve.

Order is important

To understand how all those folders come into play, let’s take a look at screen.scss, which is the primary screen stylesheet for the front end. In that file, we import several partials:

@import 'settings/_index';
@import 'tools/_index';
@import 'generic/_index';
@import 'elements/_index';
@import 'components/_index';
@import 'blocks/_index';
@import 'vendor/_index';
@import 'utilities/_index';

The import order here is extremely important. It allows you to build from base styles up to more specific styles down the line.

What each folder means

The following is a rundown of each folder and how it should be used.


The settings folder should be used to hold settings. This folder should never output any styles on its own. This is a place to add variables. I personally prefer using Sass functions for returning settings over variables. Do your own thing.


Like the settings folder, the stylesheets in the tools folder should never output styles directly. This is a good place to define custom functions, mixins, and extends that you’ll use later in your code.


The generic folder is the first place you ever want to write real CSS code. This is where you’d define a reset or normalization style. You can also do things like import a font here.


The elements folder is where you start defining specific CSS for HTML elements. You shouldn’t be using class selectors at this point. Only define your custom styles for elements.


Now we’re getting to the good stuff. The bulk of your actual code should be under the components folder. Each component (or “block” from the BEM system) should get its own file. This is where you start specifically targeting class selectors and styling them.

Mythic has a file set up and ready to go for every single component that it outputs on the front end. All you have to do is open the file and plug in rules for existing selectors.

For example, here’s a look at /resources/scss/components/_archive-header.scss:

.archive-header {

    &__title {}

    &__description {}


The blocks folder is where all the new Gutenberg (upcoming WP 5.0 editor) block styles live. These are used on both the front end and on the edit screen in the admin (see editor.scss).

Mythic separates block styles even further. By default, it has a /core subfolder for core WordPress blocks. The idea is to create extra subfolders for third-party plugins that your theme supports.

As with the components folder, Mythic already has you covered with a file for every core Gutenberg block. It even has base styles already in place for each. You merely have to adjust the style rules to suit your project.


The vendor folder should be for overrides when using third-party plugins. This can be anything from WordPress plugin integration to JS plugins that your theme is using.

Ideally, most plugins would be set up with its own components or use Gutenberg blocks in the future. In those cases, you’d want to use the more appropriate, existing folder(s).


The final folder is where everything else goes. It’s kind of a catchall for any utility classes or overrides that you might need. It’s also the only place you should ever (if you absolutely need to) use !important.

Some good uses of this folder is for handling WP’s .align* classes, accessibility rules, and similar.

Get started organizing your code

Mythic’s built-in build commands will compile all of those files down to a single .css file that’s used on the site. It doesn’t take long to switch your mind over to using ITCSS. Once you’ve got a little muscle memory for it, you’ll wonder why you haven’t already been using this system.

I’ve previously mentioned that utilizing BEM + ITCSS cut my code back 50%. That’s not me joking. When I first started working with these two systems last year, I cut a ~90kb stylesheet (minified) down to 45kb on one project.

Having clear and consistent standards that you follow means for leaner and cleaner code.

More so than just smaller production files, I’ve found it far easier to find things when I need to make a design adjustment. There are few things more frustrating than searching through 100s or 1,000s of lines of CSS looking for that one line of code where you messed up a margin value.