Because your theme uses several different modular style sheets and some of those style sheets import the content from partials, it’s important to know how to find out what file holds a specific style rule, so you can edit it directly.
The build process has accounted for this scenario by generating source maps for each style sheet. These source maps are available to the browser, so when you open the dev tools of any browser and inspect an element, the browser will tell you where that particular rule sits in the original style sheets.
In this example, you can see the inspector is telling you that the CSS is being set in _typography.css:
These source maps make it easy to navigate the original CSS files when you want to make changes to your CSS.
Remember, though: in the end, the browser is only served with the global.min.css file. The CSS from the _typography.css file sits inside the global.min.css file in a minified format.
In some cases, you may need to look at the actual minified code that’s output through the build process. (Sometimes, there are scenarios where what you write in the original files may look correct, but once it gets compiled out, something goes wrong and you need to find out what that is.)
The problem is, if you look at the actual output of these minified files, you see that they’re almost impossible to read for humans. That’s great for computers — no spaces, no wasted data. But humans cannot read this in any functional way:
For that reason, there’s a configuration setting you can use to turn the the minification off temporarily for CSS.
You find it in the “config” folder, inside the “config.default.json” file. In the “debug” section, you can change debug settings for styles, scripts, and PHPCS.
(Note: Here, debug for styles and scripts should be set to false by default, and PHPCS should be set to true. It is set to false here in the recording and in the screenshot below for technical reasons.)
In the “debug” section, having “styles” set to “false” means that the CSS that gets output is minified.
If you change this to “true” and then restart the build process, the build process will output the same exact CSS, except it won’t be minified in these files. So that way, you can actually see in a human-readable form, what the CSS looks like when it gets served to the browser.
This is only useful if you run into really serious problems and you think something is going wrong in the build process. But, it does happen, and that’s why this feature exists, so that you can directly test the code.
PostCSS settings
There’s some other interesting things related to styles inside this config file too that are worth looking at. Under the “styles” section, you’ll see it says “stage: 3”.
Stages relates to how advanced you want the features in PostCSS to be. Stage 3 means you are adopting some pretty aggressive standards when it comes to modern best practices for CSS. That means you can use modern features that are not currently available in browsers; then, PostCSS and Autoprefixer will make the code work for older browsers for you.
If you’re less willing to use modern features, you can change this number. Stage 1 would be just for current browsers. But we’d recommend leaving the setting at Stage 3, because that’s like a nice, aggressive stance on future standards.
(Reminder: If you want to change any of these settings, you do it the way we’ve outlined changing other settings in the past: you copy the entire section out and place it into config.json, matching the structure of the config.default.json file. The config.json file is where you change and customize the settings to whatever you want.)
We’d recommend leaving these defaults in place, though. Because although all these things are currently cutting edge, they will become the new standard in the future. And building standards-based code today will mean that your themes are ready for when that future comes.