Goûtez aux post-processeurs CSS !

Une fois que vous avez goûté aux variables en CSS, par exemple pour configurer un projet, pour modifier rapidement un thème, ou tout simplement pour retrouver facilement vos 100aines de variantes de bleu que vous avez écrit tantôt blue, #0000FF, #00F, rgba(0,0,255,1) ou encore #0000FE (vive la pipette !), vous aurez un mal fou à vous en passer.

C’est notamment pour cette raison que je ne peux plus envisager de projet d’intégration HTML / CSS sans l’appui d’un préprocesseur. Pour être précis, chez Alsacréations, nous avons opté pour LESS que nous compilons avec le logiciel libre Prepros.

Et pourtant, mes réticences initiales quant à ce type d’outil ne sont toujours pas complètement effacées, pour certains motifs que je vais tenter d’argumenter.

À quoi sert un pré-processeur ?

Un pré-processeur est une sorte d’extension au langage CSS pour pallier ses déficiences et apporter, entre autre, les fonctionnalités suivantes :

  • variables et constantes
  • fonctions et boucles
  • calculs et opérations
  • notation imbriquée

Les pré-processeurs interviennent en amont, avant la rédaction de CSS, puisque ce sont eux qui vont générer la feuille de style à partir d’un langage spécifique à chaque pré-processeur (LESS, Sass, Stylus).

Pourquoi je ne suis toujours pas fan des pré-processeurs ?

La syntaxe d’un pré-processeur est une sorte de métalangage inhérent à chaque pré-processeur.
En clair, si je définis une variable dans LESS, j’écrirai @kiwi; mais si j’ai adopté le langage Sass, j’écrirai $kiwi.
Et il en est de même pour toutes les autres fonctionnalités.

Comme je l’ai dit, j’apprécie sincèrement les avantages que procurent les pré-processeurs lors de la phase de développement (surtout les variables et quelques mixins/extends), mais je n’aime pas devoir écrire dans un langage qui est un détournement de CSS, non standard, bref : un hack.

Pourquoi est-ce gênant puisque de toute façon ce langage est compilé en « vrai » CSS ?
Justement, le problème se rapproche de celui des hacks en général : je suis tributaire d’un langage qui peut évoluer, voire mourir du jour au lendemain. Quand LESS disparaîtra un jour, il nous faudra reprendre une à une toutes nos feuilles de styles rédigées dans ce langage.

À quoi sert un post-processeur ?

Alors où est-ce que je veux en venir avec cette introduction longue comme le bras et mes introspections personnelles ?

J’y arrive…

À l’instar des pré-processeurs, les post-processeurs sont également des outils qui vont générer du code. Mais ces derniers interviennent sur du code CSS standard pour le « bonifier » à l’aide des plugins suivants :

  • Ajout automatique des préfixes CSS3
  • Minification CSS (et JS)
  • Concaténation (regroupement) de plusieurs fichiers CSS (et JS)
  • Réordonnement des règles CSS, voire corrections (CSSlint)
  • Ajout d’alternatives à certaines fonctionnalités (calc(), variables CSS standards, opacity, transform, unité rem, linear-gradient, inline-block,…) afin de les rendre compatibles aux anciens navigateurs
  • Etc.

La plupart des post-processeurs s’exécutent en ligne de commande, permettent de compiler du CSS, voire de surveiller un dossier (watch) et de le compiler dès qu’un contenu est modifié.

L’un des post-processeurs les plus connus est le plugin Autoprefixr, qui ajoute automatiquement les préfixes constructeurs (-moz-, -webkit-, -ms-,…) lorsqu’ils sont nécessaires.

Pour en savoir plus sur ce sujet, je vous invite vivement à lire les excellentes explications et les arguments de Vincent de Oliveira dans son article « les postprocesseurs CSS« .

Voilà donc ce que j’apprécie avant tout chez les post-processeurs : ils ne sont pas des dérivations de langage et permettent de conserver la notation CSS classique et standard.

Quelle différence avec Grunt, Gulp et Brunch ?

Grunt, Gulp et Brunch, de même que Prepros et Mixture sont des outils multitâches. Les premiers en ligne de commande, les seconds sous forme d’interface graphique.

En clair, ils permettent de tout faire. Autant côté pré-processeur que post-processeur mais aussi bien d’autres tâches (compression d’image, déploiement sur le serveur, etc.).

Forcément très pratiques dans un workflow complexe au sein d’un projet d’une certaine envergure, ces outils peuvent se révéler quelque peu exagérés lors de petits ou modestes projets.

C’est pourquoi je demeure assez attaché à des outils plus simples, plus rapidement maniables, tels que des post-processeurs.

Comparatif de quelques post-processeurs

Les post-processeurs que je connais sont :

Ils sont tous initialement basés sur des scripts de parsing de CSS tels que Rework ou PostCSS.

StyleCow Myth.io RECESS Pleeease
watch
concaténation
préfixes auto (partiel)
variables
minification
CSSlisible
source maps
compat. IE (partiel)
calc()

À suivre : un nouveau post-processeur, Pleeease

Pour finir sur le sujet, sachez que Vincent de Oliveira (@iamvdo) s’est déjà beaucoup penché sur la question et vient de sortir un outil maison qui s’annonce palpitant : Pleeease.

Il combine par défaut tous les avantages que peut procurer un post-processeur, à savoir : préfixes automatiques, variables CSS, unité rem, pseudo-éléments, media queries et minification.

PS : Pour bien comprendre ma pensée, ne confondez pas pré-processeur avec les outils tels que Grunt, Gulp, Brunch, Jade, HAML, Twig, etc. Un pré-processeur, c’est simplement le langage Sass, LESS ou Stylus. L’outil qui le compile, c’est tout à fait autre chose.

3 réflexions au sujet de « Goûtez aux post-processeurs CSS ! »

  1. Bonjour,

    Est-ce que le codage CSS que l’on retrouve dans les sites pré-conçus comme Wizishop ou Prestashop sont plutôt bien optimisé pour le référencement ou bien il faut y apporter des modifications ?

    Cordialement

    1. Bonjour,

      En toute honnêteté je ne suis ni expert SEO ni connaisseur des outils que vous citez.
      Mais surtout : quel est le rapport avec le sujet des postprocesseurs ?

Les commentaires sont fermés.