Single Page Responsive site

PostCSS, PreCSS, cssnano, animate.css,autoprefixer, gulp, graceful-fs
Project Setup & Develoment

This development was undertaken to learn PostCSS which powers an unlimited variety of plugins that read and manipulate CSS. Using SASS type features of variables(fonts, @media, color), @imports, @define-mixins, functions, image, calc() and Autoprefixer to process CSS and minify it with cssnano along with gulp to activate the processes.

Setup of the project was done with Gitbash through node and npm installing the node modules needed to work with the CSS manipulation. The setup included three folders Builds, node-modules and Process. The builds folder contained the main index.html file, images folder and outputed minified css stylesheet(which was setup in the gulpfile for the destination output).

The Process folder was setup to contain the stylesheet unminified, modules folder and sections. The stylesheet here used @import'' to load the stylesheets from the modules and section folders. In the modules folder individual .css stylesheets where created for the footer, header, navigation and section. In the sections folder individual .css stylesheets where created base.css mixins.css and variables.css. The base.css contained styles such as html, body, container, h1,h2... , img, a links and em. The mixin.css file was setup to style the main images styling and positioning as a function that could be called. The variables.css file then contained styled variables for font, colors, @media for 600px, 900px and 1200px and also container widths.

In the Gulp file I created an array of CSS processing functions and processing tasks for the css and html for the source and destination, a webserver task and a watch task which when initiated on update processed the css from the process .css stylesheet to the build .css minified stylesheet. The process of the PostCSS takes the stylesheets in the process folder and processes it to build folder to the final minified stylesheet with cssnano.
View Singlepage Site >>

CSS Postprocessors

PostCSS is a tool for transforming styles with JS plugins. These plugins can lint your CSS, support variables and mixins, transpile future CSS syntax, inline images, and more. PostCSS is used by industry leaders including Google, Twitter, Alibaba, and Shopify.

Project Installs
Postprocessors installed
  • autoprefixer
  • cssnano
  • graceful-fs
  • gulp
  • gulp-postcss
  • gulp-util
  • gulp-webserver
  • npm
  • postcss-animations
  • postcss-color-function
  • precss


PostCSS frees you from the limitations and choices imposed by preprocessor authors. The approach offers several benefits:

Modularity - You need only add the plugins and functions you require for your project.

Lightweight - Preprocessors are increasingly large and sophisticated applications. You probably won’t want or use every feature but they’re still present. PostCSS reduces the bulk.

Immediate implementation - Have you ever waited for something to become available in Sass, LibSass, LESS, Stylus or another preprocessor? You can now develop your own features using…

JavaScript functions - Your CSS preprocessor uses JavaScript — a true programming language (despite what some people say!)

Most preprocessor language constructs are basic. You’ll often see functions and mixins which are more complex and difficult to comprehend than the raw CSS they create. With PostCSS, facilities which will never be implemented in Sass/LESS/Stylus are available. You can open files, read from databases, make HTTP requests or create complex calculations with ease.

Enforce development policies - Presume you wanted your team to avoid @extend declarations. It’s no longer possible for anyone to use @extend unless they add an extend plugin to the build process. That would be immediately obvious.

It’s fast — very fast -- PostCSS is 4 – 40x faster than an equivalent preprocessor. The gains are even higher if you only require a few plugins. The whole solution is built in JavaScript and there’s no need to jump into another library or language interpreter.


PostCSS is not a perfect solution:

Increased complexity - Your build process will become more difficult to manage. Adding Sass is typically a line or two of code but PostCSS requires more planning — especially since plugins must be called in a specific order. For example, @import in-lining should be resolved prior to parsing variables. But what if you have variables within your @import declarations? In some situations it may be necessary to call a plugin more than once.

A different syntax -I initially attempted converting a small Sass project to PostCSS. Don’t even try! While I eventually succeeded, PostCSS plugins often use a slightly different syntax, e.g. @define-mixin rather than @mixin. This could lead to confusion and numerous code updates. Part of the reason…

PostCSS requires valid CSS - Most preprocessors parse plain text files so any syntax is theoretically possible. PostCSS creates an object model so it requires syntactically-correct CSS from the start. Even a // single line comment can cause it to fail. You could pre-process your CSS files before passing to PostCSS but then you’re back to using a preprocessor!