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

Converting CSS4 styles for use

The idea behind basing CSS4 around a series of modules was aimed at making it easier (and ultimately quicker) to update each standard; it does mean that modules will be in a state of flux, at least for the time being!

This said, there are some clear styles we can recreate using current CSS3 styles—one such example is CSS4 Selectors. Even though it is still in draft at the time of writing, a PostCSS plugin is available in the form of postcss-selector-not (from https://github.com/postcss/postcss-selector-not). A sister style that is also available as a PostCSS plugin is postcss-selector-matches (available from https://github.com/postcss/postcss-selector-matches)—these two are intended to replicate the :not negation and :matches pseudo-selectors that are coming as part of the new CSS4 standard.

Note

For more information on individual CSS4 selectors, take a look at the full list available at http://css4-selectors.com/selectors/. This will also give you an indication of available browser support—this list will be updated with changes as selectors are ratified for use.

Looking further afield, there are a small handful of plugins that provide support for upcoming CSS4 standards—in addition to the :matches and :not plugins, we can use any of the following:

Name of plugin

Purpose of plugin

mq4-hover-shim

Currently in beta, this plugin provides limited support for the Media Queries Level 4 hover media feature—it is available from https://github.com/twbs/mq4-hover-shim.

host

Working with the Shadow DOM? If you need to make :host selectors work properly with pseudo-classes, then this plugin is for you—the source is available at https://github.com/vitkarpov/postcss-host.

pseudo-class-any-link

How many times have you had to add pseudo-selectors such as :link or :visited to your code? This PostCSS plugin fixes that—we can now use the proposed :any-link pseudo-class in CSS.

Head over to https://github.com/jonathantneal/postcss-pseudo-class-any-link for more details.

postcss-initial

The PostCSS Initial plugin resets a specified property's value to what it was initially set in code (and not by the browser). For more details, head over to https://github.com/maximkoretskiy/postcss-initial.

font-variant

This plugin transforms font-variant settings to the equivalent font-feature-settings value—it is designed for special cases, when it is not possible to reproduce using normal means, for example, a slashed zero to differentiate between a 0 and an O—the former equates to zero.

The source for the plugin is available at https://github.com/postcss/postcss-font-variant.

postcss-input-range

This plugin allows us to style input range elements. We need to provide unprefixed CSS styles, and the plugin will automatically handle support for all of the various prefixes required to allow this element to be styled across different browsers.

The source for this plugin can be downloaded from https://github.com/jonathantneal/postcss-input-range.

Okay, let's move on: I feel a demo coming! Let's take a look at using the postcss-selector-matches property, to see how we can use it in action.

Validating e-mail addresses

How many times have you come across e-mail submissions from your site, where you aren't 100% sure your visitors have left a valid e-mail address?

If we leave aside exact numbers, it goes without saying that any requests submitted from any website must have a valid e-mail address; with the plethora of top level domains that are now available, it's even more critical that they be valid!

To help with this, we can use the :invalid and :valid attributes to style <input> fields—whilst they may not be able to tell if .design is a valid TLD (and yes, it is), they can at least cope with the basics of ensuring that you have a TLD present, an @ symbol, and the name of a recipient.

Tip

You can perform a test in your browser to gauge support for these and other CSS4 selectors—check out the CSS4 Selectors site, at http://css4-selectors.com/.

Let's knock up a simple example using the postcss-selectors-matches plugin for PostCSS, to see how we can style such fields:

  1. We'll start as always by firing up a Node.js command prompt session, then changing the working folder to our project area.
  2. At the prompt, go ahead and enter this command, then press Enter:
    npm install postcss-selector-matches --save-dev

    Keep the window open, we will need it shortly. If all is well, we should see this appear:

    Validating e-mail addresses
  3. Next, extract a copy of the T69 - matches pseudo-selector folder from the code download that accompanies this book, and save it to the root of our project area.
  4. Copy matches – pre-compile.css from the css—completed version folder within T69 - matches pseudo-selector, and save it to the src folder at the root of our project area.
  5. Copy the gulpfile.js and package.json files from the T69 - matches pseudo-selector folder to the root of our project area, and rename it matches.css
  6. Revert to the Node.js command prompt session from earlier, then at the prompt enter gulp and press Enter.
  7. If all is well, PostCSS will go away and compile our code into valid CSS—we should see the now familiar files appear in the dest folder.
  8. Copy the contents of this dest folder to the css folder underneath T69 - matches pseudo-selector, then try previewing the matches.html file in a browser. If all is well, we should see something akin to this:
    Validating e-mail addresses

It's a simple demo, and yes, somewhat contrived. At this level, it wouldn't be necessary to use :matches, as it ends up generating more code than is necessary! But it does show how easy it is to apply the technique, and have it provide valid CSS, as in the case of our example:

Validating e-mail addresses

Okay, let's change tack: we will stay with the range theme for our next demo, but this time look at a more stylish example, where we can really go to town on transforming the appearance of our selected element.

The range input element is one that has been traditionally hard to style, more often than not, we may end up resorting to using jQuery UI to change its appearance! Not so with CSS4—we can use a series of new CSS attributes to apply styles, without the use of any additional libraries. Let's take a look at this in more detail.

Supporting the new range input

A quick question, how many times have you had to create a site where you needed to choose a value, say from 1 to 100? Or pick a specific opacity of color, from almost transparent to completely opaque?

Okay, perhaps they're an odd couple of questions to ask, but the eagle-eyed should spot that I am of course referring to using sliders, which we can adjust to select a specific value. There are different ways to add these to a page, but which in the main will require some help to style, perhaps the most recognizable tool being jQuery UI!

This is fine if we need to use jQuery UI in our pages to provide other functionality, but what if we only needed it for the slider? It's a bit of overkill—thankfully, we can fix that with the use of the postcss-input-range plugin, available from https://github.com/jonathantneal/postcss-input-range. It's time for that demo, so let's knock up a quick example of how one can be styled to represent a progress bar:

  1. We'll start by installing the postcss-input-range plugin, for this, go ahead and fire up a Node.js command prompt, then change the working folder to our project area.
  2. At the prompt, enter the following command, then press Enter:
    npm install postcss-input-range --save-dev

    If all is well, we should see something akin to this screenshot:

    Supporting the new range input
  3. Next, extract a copy of the T70 - using range input folder from the code download that accompanies this book. Go ahead and save it in our project area.
  4. In the css folder of T70 - using range input, copy the range – pre-compile.css file to the src folder of our project area, and rename it range.css.
  5. Copy the gulpfile.js and package.json files from the T70 - using range input folder to the root of our project area.
  6. Revert to the Node.js command prompt window, then at the prompt enter gulp and press Enter.
  7. Gulp will now run our compilation process, if all is well, we should see the now familiar style sheet files appear in the dest folder, along with a map file in the maps subfolder. Copy these to the css folder under T70 - using range input.
  8. If all is well, we should see something akin to this screenshot when previewing the results in a browser:
    Supporting the new range input

There is nothing complicated in this demo, even though we've only scratched the surface of what is possible when styling the range element—for example, we can add datalists to define certain values to scroll through, such as specific times of the day.

Browser support is still limited, but for an idea of what is possible, check out http://demo.agektmr.com/datalist/; the CSS guru Chris Coyier also has a couple of articles on the use of range inputs on his site at http://www.css-tricks.com.

The real magic in our demo appears when we take a look at the compiled code—one of the key elements for styling a range input is the range-thumb attribute, which is the knob we use to select a value on the slider. Here are two examples of how our code now looks, with support added for Firefox:

Supporting the new range input

This has support for Internet Explorer (which has been superseded by Edge):

Supporting the new range input

When using this plugin, we don't have to worry about adding vendor prefixes—our original code contains just the unprefixed versions; the relevant prefixes will be added at compilation, until such time as they are no longer needed for styling our input element.

Tip

If you would like help with styling the new range input element, then check out http://danielstern.ca/range.css/—it's a useful tool!

Over the course of the last two demos, we've briefly scratched the surface of what is possible when using PostCSS—we've used the same format of Gulp task file to incorporate support for each plugin, which when run, has produced the requisite CSS style sheet for each demo. Nothing outrageous here, right? After all, it's followed the same principles we covered earlier, such as one plugin for one task…or can we do better?

Yes, by now you should know that I always like to go one better if I can. Remember how I said it is preferable to create tasks in our runner that worked on a one-to-one basis? Was each task in our (Gulp) file related to a specific plugin? Well, as someone once said, rules are meant to be broken—it's time to throw out the rulebook, and consider a different approach, at least for future syntax…