Although many developers have moved on from using preprocessors to using PostCSS, it is important to note that PostCSS is not a replacement, just an alternative way of preprocessing CSS styles. To help with the transition, we're not forced to learn a new syntax. Using a handful of plugins, we can take advantage of the speed of PostCSS, while still using syntaxes that we're accustomed to, such as Less, SASS, or Stylus.
In this chapter, we'll take a look at the plugins that make this possible, and work on some simple examples that show you how using a custom syntax that we're all familiar with is still possible when using PostCSS.
This chapter will cover the following technical topics:
Let's make a start!
W3Schools defines a CSS syntax as follows:
"A CSS rule-set consists of a selector and a declaration block: The selector points to the HTML element you want to style. The declaration block contains one or more declarations separated by semicolons."
We as developers spend many hours crafting sites; this can be something small as a one-page contact card-type site, right through to a large e-commerce website. It does not matter which styles we decide to use, or how we get there: the key is that the final result must use the same standard syntax that we've grown to love over the years.
This does not mean to say that our source should be standard CSS, in fact, it would be very restrictive if this were the only option! We could use libraries such as SASS or Less, but instead, how about using the API and custom syntax plugins to manipulate our styles directly? We touched on some of the principles back in Chapter 8, Creating PostCSS Plugins; it's time to revisit this and explore how we can begin to remove this restriction.
Why would we want to do this, I hear you ask? The answer's simple—let's assume for a moment you create themes for WordPress. WordPress' default themes are created using SASS (and PostCSS); this means a dependency on SASS in some form. We can mitigate this a little by using the gulp-sass plugin, but this still uses libsass to compile code.
What if we could turn this on its head, and use the API and custom syntax plugins that parses SASS code and converts it to PostCSS equivalent? Okay, granted, we may not be able to cover all styles; we can at least make a start on converting some, and reduce our dependency on using SASS. Let's make a start. Before we get stuck into producing code, we have a simple administrative task to perform: we need to install a syntax highlighter first.