CSS Custom Properties (aka variables) allow you to define a property once and use it many places. WP Rig enables CSS custom properties in a limited fashion via cssnext.
One major frustration when working with CSS is you often have to declare a property in multiple different rules, but you want it to stay the same. That could be a font family, or a color, or a margin, or a width, or something else. And any time you need to make an update to that font family, or color, or whatever, you have to make an update to every single instance of that property, which is just opening a door to a bunch of errors.
To get around this problem, preprocessors like Sass introduced variables. You declare the value once in a variable, and then you just call that variable later on. Then, if you want to change the value, you change it in the variable, and the change will propagate throughout the rest of the stylesheet.
Now, we have that same functionality in pure CSS, only it’s not called “CSS Variables”, it’s called “CSS Custom Properties”. But it’s exactly the same thing.
It’s pretty straightforward: you declare a new custom property by giving it a name, dash, dash, and then whatever name you want, and then you put whatever value you want in that custom property, next to it just like a regular property. Then, when you want to use the custom property, you call it saying “var” and then just call the name you declared in parentheses.
This works across all modern browsers. Anytime a modern browser sees this, it’ll replace the call to the custom property with a value in the custom property. However, this does not work in some older browsers. Older browsers will see this and just assume nothing is there. It won’t call an error, it’ll simply not understand it and just move on. That means if you want to use custom properties and you want to support older browsers, you need to provide a fallback.
The way we do that is by declaring the exact same property directly above. So in this case, background-color, and then put in the actual value. So the first color value here, which is the hex value. This introduces a bit of a roadblock for one of the cool features of custom properties, which is nesting and scoping, but if you want to have backwards compatibility right now, you need to provide these fallbacks, which sounds like a lot of work, right? You have to first declare it a custom property and then you also have to put in the hard-coded value.
The good news is in WP Rig, this is all handled for you. WP Rig ships with full support for custom properties and also uses custom properties extensively in the original theme. The custom properties themselves are declared in the custom properties partial. They’re all declared on root so that they apply to absolutely everything in the entire document. This is to counteract that problem of scoping and to ensure that fallbacks work properly.
It does limits what you can do. You can’t do scoping and nesting, but you can still use custom properties to do what you want to. These custom properties are used throughout the different stylesheets. You can see an example inside the Typography partial. There is a color custom property, the font family, the font size, and the line height. In _custom-properties.css, there’s a lot of other custom properties declared as well. The idea here is, instead of going through the entire pile of stylesheets and changing values anytime you want to change something, you simply go and change them here or add new custom properties in this file, and then you’d use the custom properties wherever they appear for consistency throughout the theme.
But, of course, there is the important question, what happens to older browsers? The build process in WP Rig solves this problem via Autoprefixer. For example, in the image below, there is the anchor element with the var(–color-link) custom property applied. That’s what’s active in Firefox because this is a modern version of Firefox. But directly above, there is also the hard-coded hex value.
This is what Autoprefixer has done to make my custom properties work in older browsers as well. So if I were using an older browser, instead of using the custom property here, it would just use that hex color value.
The reason why this is important, and the reason why you should use custom properties — even though you get this hard-coded fallback — is in the future, (quite shortly in the future) all browsers will support custom properties. Then, you’ll already have wired things up, and you can simply remove the custom properties fallback from Autoprefixer. Everything will then just work the way it’s supposed to.
There is another caveat: you cannot use custom properties to create media queries. There are some important reasons why that doesn’t work — but the reality is it doesn’t work. Which is unfortunate, because you would want to use variables in media queries, right?
In WP Rig, you can. Notice there’s another partial file called _custom-media.css. Here, we define custom media properties that work the exact same way as custom properties, except they’re for a custom media. The thing is, custom media properties are not supported by any browsers anywhere. This is so bleeding edge that it’s not supported at all, but we can still use it in the way it will eventually be supported in browsers right now in WP Rig, thanks to PostCSS and Autoprefixer.
So just like with custom properties, we also use custom media, meaning you define your media queries in this file, and then they get populated throughout all your CSS files.
How is this used? Well, if you go to global.css and take a look, there is a call, @media, and then we call for –narrow-menu-query. – -narrow-menu-query is defined in _custom-media.css, and it’s right here, –narrow-menu-query, and the value is, screen and (max-width: 37.5em).
So, custom properties and custom media can be used in WP Rig, and I urge you to do it because this is how we are going to write CSS in the near future.