Table of Contents for
Mastering PostCSS for Web Design

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering PostCSS for Web Design by Alex Libby Published by Packt Publishing, 2016
  1. Cover
  2. Table of Contents
  3. Mastering PostCSS for Web Design
  4. Mastering PostCSS for Web Design
  5. Credits
  6. About the Author
  7. About the Reviewer
  8. www.PacktPub.com
  9. Preface
  10. What you need for this book
  11. Who this book is for
  12. Conventions
  13. Reader feedback
  14. Customer support
  15. 1. Introducing PostCSS
  16. Introducing PostCSS
  17. Setting up a development environment
  18. Creating a simple example using PostCSS
  19. Linting code using plugins
  20. Exploring how PostCSS works
  21. Summary
  22. 2. Creating Variables and Mixins
  23. Creating a hover effect example
  24. Transitioning to using PostCSS
  25. Adding variable support to PostCSS
  26. Updating our hover effect demo
  27. Setting the order of plugins
  28. Creating mixins with PostCSS
  29. Looping content with PostCSS
  30. Summary
  31. 3. Nesting Rules
  32. Navigating through pages
  33. Transitioning to using PostCSS plugins
  34. Exploring the pitfalls of nesting
  35. Making the switch to BEM
  36. Exploring our changes in more detail
  37. Summary
  38. 4. Building Media Queries
  39. Exploring custom media queries in PostCSS
  40. Making images responsive
  41. Adding responsive text support
  42. Optimizing media queries
  43. Retrofitting support for older browsers
  44. Moving away from responsive design
  45. Taking things further with CSS4
  46. Summary
  47. 5. Managing Colors, Images, and Fonts
  48. Managing fonts with PostCSS
  49. Creating image sprites
  50. Working with SVG in PostCSS
  51. Adding support for WebP images
  52. Manipulating colors and color palettes
  53. Creating color functions with PostCSS
  54. Summary
  55. 6. Creating Grids
  56. Creating an example with Bourbon Neat
  57. Exploring the grid plugins in PostCSS
  58. Transitioning to using PostCSS-Neat
  59. Creating a site using Neat and PostCSS
  60. Adding responsive capabilities
  61. Summary
  62. 7. Animating Elements
  63. Moving away from jQuery
  64. Making use of pre-built libraries
  65. Switching to using SASS
  66. Making the switch to PostCSS
  67. Exploring plugin options within PostCSS
  68. Updating code to use PostCSS
  69. Creating a demo in PostCSS
  70. Optimizing our animations
  71. Using our own animation plugin
  72. Summary
  73. 8. Creating PostCSS Plugins
  74. Dissecting the architecture of a standard plugin
  75. Creating an transition plugin
  76. Building a custom font plugin
  77. Simplifying the development process
  78. Guidelines for plugin building
  79. Making the plugin available for use
  80. Summary
  81. 9. Working with Shortcuts, Fallbacks, and Packs
  82. Exploring plugin packs for PostCSS
  83. Adding shortcuts with Rucksack
  84. Linting and optimizing your code
  85. Providing fallback support
  86. Summary
  87. 10. Building a Custom Processor
  88. Exploring our processor
  89. Dissecting issues with our processor
  90. Optimizing the output
  91. Adding reload capabilities
  92. Extending our processor further
  93. Testing the final pre-processor
  94. Getting started with some hints and tips
  95. Introducing the CSStyle library
  96. Summary
  97. 11. Manipulating Custom Syntaxes
  98. Preparing our environment
  99. Implementing custom syntax plugins
  100. Parsing CSS
  101. Formatting the output with the API
  102. Highlighting our syntax code
  103. Summary
  104. 12. Mixing Preprocessors
  105. Exploring the conversion process
  106. Introducing the Pleeease library
  107. Compiling with other preprocessors
  108. Using the PreCSS library
  109. Converting a WordPress installation
  110. Setting up our environment
  111. Considering the conversion process
  112. Making changes to our code
  113. Compiling and testing the changes
  114. Summary
  115. 13. Troubleshooting PostCSS Issues
  116. Exploring some common issues
  117. Getting help from others
  118. Summary
  119. 14. Preparing for the Future
  120. Converting CSS4 styles for use
  121. Supporting future syntax with cssnext
  122. Creating plugins to provide extra CSS4 support
  123. Summary
  124. Index

Exploring the conversion process

Cast your mind back to Chapter 10, Building a Custom Processor, for a moment.

The key theme of that chapter was bringing together a number of plugins we covered throughout the preceding chapters, to create what would become our processor. So far, all of the plugins used were based around pure PostCSS, so they wouldn't be able to compile raw SASS code.

We took a brief look at the CSStyle library, as a possible means of getting around this—it's a great library for producing clean code using BEM principles, but it requires that code is written using a specific format. Ordinarily, there is nothing wrong with this at all—every developer's utopia should be to produce clean, efficient code, right?

Yet there is just one small problem, reality! It wouldn't be practical to rewrite a large, complex e-commerce site to use CSStyle without an enormous amount of work; it would require a lengthy transition period to effect such a change. It's not impossible, but using BEM-style notation is better done from ground up, or at least in defined chunks, if your site has multiple style sheets in use.

So if using CSStyle isn't a practical solution for our needs, how can we make that change? There is a more practical solution available to us—it may take longer, but the disruption should be reduced, and allow us to make smaller changes to our code in a more manageable transition process:

  • We start by introducing a task runner to compile existing processor code—plugins exist for using libraries such as SASS or Less within runners such as Gulp or Broccoli, to allow us to compile code.
  • Once we've transitioned to using a task runner, we can then introduce plugins to handle core processes, such as managing vendor prefixes, creating source maps, and minifying our style sheets.
  • We can then break down our existing style sheet into smaller chunks and import each into a master file during compilation. Each can then be converted to use PostCSS plugins that replicate existing processor functionality—for example, we might use postcss-simple-vars to create new variables to replace existing SASS-based examples.

The latter step in this process should be iterative, at least until everything has been converted, and allows us to remove any dependency on existing processors. We've used a fair number of Gulp task files to date, so we should be reasonably familiar with the basic use of one by now—here's what a task file might look like, if we were using SASS and Gulp:

var gulp = require('gulp');
var postcss = require('gulp-postcss');
var sass = require('gulp-sass');
 
var autoprefixer = require('autoprefixer');
var cssnano = require('cssnano');
 
gulp.task('css', function () {
  var processors = [ autoprefixer, cssnano ];
  return gulp.src('./src/*.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(postcss(processors))
    .pipe(gulp.dest('./dest'));
});

In this example, we're using the Gulp plugins for SASS and PostCSS—SASS code is compiled first, before vendor prefixes are added by PostCSS, and the code is minified into the final article.

The benefits of this process, though, mean that we can control the rate of conversion—we are not forced to have to convert everything in one go, and can be selective about what is converted at each point in the process. There will still be a dependency on an external library, but this is temporary; we can remove that dependency when everything has been converted to using PostCSS.

Choosing our plugins

Assuming that we've made the transition process to using a task runner, then where do we go from here?

Well, it's time to choose the plugins we need to use, based on the functionality offered by our site. Some of the more useful plugins to get you started are as follows:

Plugin

Purpose of plugin

postcss-mixins

If your code contains SASS mixins, then this will be essential—the format is very similar, so changes can be made using a search and replace in your editor. The plugin is available from https://github.com/postcss/postcss-mixins.

postcss-nested

Nesting code in SASS is a key concept—the postcss-nested plugin from https://github.com/postcss/postcss-nested is a good choice for replicating this functionality within SASS.

Coupled with this, the postcss-nested-props and postcss-nested-vars plugins can be used to unwrap any properties or variables that are in nested code.

postcss-sassy-mixins

There are occasions when we might have blocks of reusable code; we can use mixins to help reduce the amount of code written in our style sheets.

A key concept borrowed from SASS, this plugin replicates the same functionality, and allows us to easily convert from using SASS to PostCSS. The plugin source is available from https://github.com/andyjansson/postcss-sassy-mixins.

postcss-simple-extend

If we have styles that share common elements, then we can remove some of this duplication by extending existing styles. This is a common practice when using SASS; the postcss-simple-extend plugin from https://github.com/davidtheclark/postcss-simple-extend is perfect for replicating this within PostCSS.

Other plugins are available, depending on your needs. The majority of plugins available are for SASS, but that is simply due to its maturity; others will no doubt become available for processors such as Less or Stylus over time.

Tip

Take a look at the PostCSS plugins catalog available from http://postcss.parts for more details.

Adding single plugins is a perfectly acceptable option, but what if we're adding more than just a couple of plugins to mimic SASS code? There are two options that would be useful here, and which we've not covered in our list—using the PreCSS or Pleeease libraries.

The Pleeease library was designed to handle some of the more menial tasks that are a necessary evil when compiling our code. Although not all of the supported tasks will apply, there will be at least three that do—minifying code, adding vendor prefixes, and generating source maps.

In stark contrast, the PreCSS library is likely to be more useful, as it is a collection of plugins that emulate SASS features. The beauty, though, is that we only need to install one plugin to handle changes; PreCSS abstracts the manual conversion of PostCSS styles into valid CSS using a single interface. We will explore using it in more detail a little later on in this chapter, but for now, let's turn our attention to putting the Pleeease library through its paces.