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

Introducing PostCSS

At the beginning of this chapter, I mentioned that we would focus on creating our own preprocessor, right? Well, I have a little confession to make: we're not. Hold on, what gives?

Well, we will create a preprocessor…but we will also create a postprocessor too. Let me explain why—our alternative "option" allows us to create both at the same time. Our alternative option is PostCSS, which can be downloaded from https://github.com/postcss/postcss. PostCSS is used by some major companies, such as Twitter, Google, Bootstrap and CodePen, and even WordPress (in a limited capacity).

PostCSS was built as a Node.js module, so will work with any number of the existing plugins already available for Node.js—we will be using a number of these plugins throughout the book. Let's take a moment to explore some of the benefits of this tool.

Exploring the benefits of using PostCSS

What do we mean by PostCSS? In a nutshell, it can be used to refer to one of two things—the PostCSS core tool or the plugin ecosystem that is powered by the tool. On its own, it doesn't actually do a lot; once we start adding plugins, we can achieve a great deal. Let's explore what this means in practice:

  • Its modular architecture means we can pick and choose what we use; this allows us to keep the size of the library very small and responsive.
  • Existing processors tend to fall into one of two camps—pre- or post-processing—which is a limiting factor when choosing which to use. PostCSS allows us to perform both operations within the same process, meaning we get the benefits of both worlds of processing!
  • PostCSS comes with seamless support for all of the common task runners such as Gulp, Grunt, or Broccoli; we can combine it with a number of other tasks that can be automated.
  • There are no dependencies for compiling, PostCSS is written entirely in JavaScript, so no need for Ruby, or libraries such as libsass, in order to compile code. The only dependency (as such) is Node.js—many developers will likely already have this installed.
  • There is no need to learn any new languages; every developer will be familiar with JavaScript, and use it in their development process.
  • We can change any plugin in use for something else when needed; we do not get this choice when using a larger library.
  • Its relatively low barrier of entry means we can create any plugins we need very easily, or potentially modify existing ones to better suit our needs.
  • PostCSS is quick—in a test using the postcss-benchmark plugin (available from https://github.com/postcss/benchmark), which contained parsed code, nested rules, mixins, variables, and math, PostCSS came out a clear winner:
    Exploring the benefits of using PostCSS
  • Perfect—no need to continually update SASS, or have to download a new version of the libsass library, right?

Considering some of the pitfalls

Well, there are some considerations to using a custom processor; the key thing to remember is that PostCSS is neither a pre- nor post-processor, but more of a Swiss Army Knife of a toolbox that we can use to process our CSS code. Let's take a look at some of these drawbacks:

  • Although we don't need to learn a new language in order to use PostCSS, creating a custom processor will add a layer of complexity to our development process.
  • Its flexible approach means some may treat PostCSS as either a preprocessor or a postprocessor; this short-sighted approach means that you will miss opportunities, so it is crucial to keep an open mind in terms of what PostCSS can offer your development process.
  • Converting code from an existing preprocessor to using PostCSS can be painful; this process only works if we don't try to convert explicitly, but use it as a basis for progressively moving to using PostCSS.
  • PostCSS requires syntactically correct CSS from the start; although we could use any syntax (as PostCSS files are just plain text), compilation can easily fail, even through use of a single line comment!
  • The real benefit of using PostCSS, though, is in its seamless integration into tools such as Gulp—imagine this scenario if you will:

You already develop sites using a preprocessor such as SASS. You can compile code using a standalone processor, but normally prefer to use Node.js and Gulp to complete the task. Sound about right? What about making the move to using PostCSS?

No problem, we can include a section for processing CSS files using PostCSS. The key here is to not use PostCSS to perform the initial compilation, but to perform the post-processing, such as adding vendor prefixes or minifying the results. Once this is established, we can start to incorporate some of the plugins available for PostCSS that allow us to replicate functionality, such as from within SASS. Once we've adjusted existing code to use the format required by the plugins, we can then switch to using PostCSS, and begin to remove our dependency on using SASS.

Clearing up some misconceptions

At this point, it is worth spending a few minutes to help clear up some common misconceptions about PostCSS, although many associate it as being a preprocessor, or even a postprocessor, this isn't what was intended:

  • Classing PostCSS as a postprocessor, as opposed to a preprocessor (such as Less or SASS) is misguided; PostCSS is capable of compiling in a variety of different use-case scenarios, working on code compiled using any preprocessor, or just plain CSS.
  • PostCSS should not be classed as a tool that should be tied in to any one process (such as writing SASS-based loops or conditionals). There are plugins available to do both, but this is just a small part of the role that PostCSS can play in your development workflow.
  • If you find yourself in a position where "PostCSS" doesn't appear to perform as expected, it is unlikely to be PostCSS itself, but more likely to be a plugin being used that is causing the issue. Although PostCSS is still relatively young, there are plenty of plugins available, so it is worth trying alternatives if you can as a first port of call.

Okay, let's move on, I think it's time for less chat and more action, right? Let's get stuck in to producing something; there's no better time than now to get PostCSS installed and ready for use.

Preparing for exercises in this book

Before we do so, we just need to cover a couple of requirements. First, we need to set up a local web server. It's not critical, but gives a better effect. I personally use WAMP Server (for PC, from http://www.wampserver.com/en), otherwise, Mac users can try MAMP (http://www.mamp.info/en), or the cross-platform Apache web server (from http://www.apachefriends.org). In each case, default settings should be sufficient.

The second requirement is to set up a project area; assuming you have set up a WAMP as a local web server, go ahead and set up a folder called postcss in c:\wamp\www, as shown in this screenshot:

Preparing for exercises in this book

Right, with that out of the way, let's make a start on getting PostCSS installed!