Where does one start, when working with an average WordPress style sheet, I hear you ask?

Well, the first thing we should not do is be put off by its size. Yes, I know this might sound crazy (after all, the Twenty Sixteen theme weighs in at 3920 lines!), but with some planning, we can easily break this into something more manageable.

If we only achieve one task with PostCSS, then that task must be to make use of the postcss-import plugin to help break our code into more manageable principles. If you happen to have used processors such as SASS or Less, then it's the same principle—in our master style.css, we can create a series of import statements, and hive off each block into separate files.

Once we've broken the style sheet into more manageable chunks, there are a fair few things we can implement in our code; we should always consider it an iterative process, until such time as we exhaust all possible alternatives, the site is no longer required, or we migrate to a different solution. Over the next few pages, we'll cover some of the ideas and considerations that are likely to crop up—this should help get you started with making the changes to your theme. So without further ado, where do we start?

Well, the obvious one is using Autoprefixer; WordPress makes good use of CSS3 styles, of which a fair number still require vendor prefixes. A consideration here, though, is that as we will be working backwards from the original style sheet, we will need to strip out existing vendor prefixes and set our task runner to add these in automatically. It's a necessary evil of working with existing style sheets in WordPress, but at least we should only have to do it once! There may be a temptation to create a mixin to manage vendor prefixes, but this is not considered best practice—Autoprefixer will update styles at each compilation.

We're already familiar with using Autoprefixer from earlier examples—in the same vein, we can also consider minifying our code, which will help reduce bandwidth usage. Adding such a facility should be a cinch—we can use the same tasks from earlier demos, as long as we set the right order of tasks. We will need to alter it to compile style.css directly (this is the main file for WordPress style sheets), but as our processor will be geared towards using WordPress, this won't be an issue.

Another area we can look at is rem unit support, with pixel fallback. Many developers have their own views on using rem as a unit of measure; some say pixel values work just as well, but its suitability will depend on where it is being applied. This aside, Gulp has a suitable plugin we can use to help provide this functionality, if we need it.

One way to really make an impact on our code is to use nesting—this is a common technique for preprocessors such as SASS, and involves writing code in a nested format. The key benefit is to remove code that is duplicated—consider it a form of shorthand (in a manner of speaking), which will be transformed into valid CSS at compilation.

A useful technique to also look at is the use of variables; these work in much the same way as scripting or programming languages. Now before you go running for the hills, don't worry: they are easy to use. We need to provide a list of placeholder names, and the values they represent; we can then do a search and replace throughout our code for each value, and replace it with the appropriate variable. Why do this, I hear you ask? Well, it's simple: if you change a color in the future, you only need to change it in one place; PostCSS will automatically change all other instances for you at the compilation stage.

If you would like to really get stuck into the core code for WordPress, then it's always worth exploring the code repository at https://core.trac.wordpress.org/browser/trunk/. If you look carefully, you should even see where PostCSS is being used!

Okay, enough chitchat: let's get stuck into some code! The changes we will make as part of our next demo are just some of the ways in which we can incorporate the use of PostCSS plugins (or Gulp, for that matter), into our process. We'll begin by exploring the changes we need to make, and follow this with some ideas for you to try out as part of using PostCSS.