#postprocesseur

[iamvdo]

Myth, un post-processeur CSS

Il y a moins d'un mois, j'écrivais un article sur les post-processeurs CSS et je m'interrogeais, publiquement, sur l'intérêt de tels outils, comparés aux pré-processeurs. Je trouve l'idée très prometteuse. Le concept de conserver son CSS «propre», «future-proof» pour pouvoir y appliquer toutes sortes de traitements automatiques offrant un support maximal m'enchante.

Sauf que, tout n'est pas réalisable. Je suis allé un peu trop loin dans mon cheminement, et j'ai franchi la limite à ne jamais dépasser: la cascade CSS et le DOM.

Alors oui, cela dépend des actions effectuées, le fameux «ça dépend». Par exemple, l'utilisation d'Autoprefixer pour l'ajout des préfixes CSS en post-traitement est à préconiser sur l'utilisation des pré-processeurs (attention, je ne parle pas d'outil comme prefixmycss qui ajoute les préfixes au sein du navigateur). L'utilisation d'un polyfill pour les filtres pourrait l'être également.

Par contre, lorsque je parle de polyfill pour les variables CSS ou calc(), il faut faire attention.

Myth.io

Hier soir a été annoncé Myth. C'est une sorte de super-polyfill-post-processeur pour votre CSS, exactement ce dont je parlais. Et avec, les limites apparaissent. Reprenons les différents exemples de code proposés sur le site.

Les variables

/* CSS en entrée */ :root { var-purple: #847AD1; } a { color: var(purple); } /* CSS en sortie */ :root { var-purple: #847AD1; } a { color: #847AD1; }

Les variables CSS sont dans l'actualité cette semaine, depuis l'annonce de la prise en charge par Firefox dans la version 29. Mais, il faut faire attention, car les «variables CSS» n'en sont pas réellement. Ce sont en fait des propriétés personnalisées. Et ces propriétés fonctionnent en suivant le principe même de CSS, la cascade! Les propriétés personnalisées sont uniquement connues dans le scope où elles sont définies, ce qui n'est pas le cas avec cet outil.

Les variables, telles que présentées par Myth ne sont en fait «que» de simples variables, et non réellement des propriétés personnalisées, comme le prévoit CSS. Il y a donc tromperie sur la marchandise.

Certes, cela peut s'avérer utile si le développeur reste rigoureux (ou si le plugin l'est pour vous ) et ne crée que des variables globales, mais le détournement d'une syntaxe normalisée pour en faire autre chose peut s’avérer dangereux. De plus, le code n'est plus «future-proof», comme espéré au départ.

Mathématiques et couleurs

Là encore, les exemples présentés sont trompeurs. Regardez mieux:

/* CSS en entrée */ pre { margin: calc(var(large) * 2); } /* CSS en sortie */ pre { margin: 20px; }

Cet exemple fonctionne ici avec l'utilisation d'une variable, mais qu'en est-il pour une autre utilisation de calc(), plus classique? Par exemple combinant unités relatives et absolues comme calc( 50% - 25px ) (ce qui équivaut à 50% de la largeur de son containing block moins 25px) Bien entendu, ni un pré-processeur, ni un post-processeur ne pourront résoudre ces problèmes contextuels inhérents au document sans en connaitre sa structure.

Dans ce cas, votre CSS est bien préparé pour l'avenir, mais aucun outil ne pourra vous venir en aide pour offrir un meilleur support navigateur.

Il en est de même pour l'exemple des fonctions de couleurs. Dans ce cas, c'est même encore plus problématique puisque la spécification n'en est qu'à ses balbutiements, et donc non stable. Il serait dangereux d'utiliser du code non normalisé, ou non en passe de l'être. De plus, la logique précédente s'applique, il n'est pas possible de profiter de la cascade CSS.

/* CSS en entrée */ a { color: color(var(purple) tint(20%)); } /* CSS en sortie */ a { color: rgb(157, 149, 218); }

Conclusion

Même si le principe est intéressant sur la forme, l'objectif principal ne peut (et ne pourra) jamais être atteint. Après l'annonce d'hier, j'ai immédiatement montré ma satisfaction, mais sans vraiment prendre la mesure de ce que Myth nous propose. En réalité, et après étude, il s'avère que ce post-processeur propose moins de choses que ce qu'a tenté récemment Nicolas Gallagher avec rework-suit, son post-processeur (ou pré-processeur transparent). Rework-suit propose le support des variables (identiques à Myth, puisque basé sur le même plugin), les préfixes automatiques avec Autoprefixer, ainsi que le support de l'opacité pour IE8.

[iamvdo]

Les postprocesseurs CSS

C’est la tendance qui se dégage depuis quelques mois. Notamment depuis la démocratisation des outils d’automatisation du workflow front-end, comme Grunt.

Les postprocesseurs CSS, dont le nom évoque directement les préprocesseurs, sont en fait toutes les étapes qui devraient être effectuées en post-traitement, sans que le dev ne se soucis de cela. L’intérêt étant d’écrire du code CSS propre, sans préfixes, maintenable, voire à la pointe, afin d’obtenir en retour un code compilé pour un maximum de compatibilité.

Actuellement, on peut évoquer Rework et PostCSS qui vont plus ou moins dans cette direction.

Automatiser les préfixes

La première tâche à postprocesser, c’est l’automatisation des préfixes CSS. En effet, avant l’arrivée des préprocesseurs, et avant que les navigateurs ne soient aussi à jour, il fallait répéter les préfixes, souvent plusieurs fois. Par exemple, il y a quelques années, une transition CSS s’écrivait plus ou moins de cette façon, et c’était pénible:

.element { -webkit-transition: background 1s ease; -moz-transition: background 1s ease; -ms-transition: background 1s ease; -o-transition: background 1s ease; transition: background 1s ease; }

Du coup, les préprocesseurs & Co. (comme Sass et Compass) ont permis de s’affranchir de cela en écrivant quelque chose du style:

@import "compass/css3"; .element { @single-transition(background, 1s, ease) }

qui génère le CSS adéquat. Mais, même si l’on pourrait penser que c’est mieux, ça ne l’est pas (en tout cas pour les préfixes). Certes l’outil travaille pour nous, mais le code manipulé s’éloigne du CSS, et certaines fois énormément. Mais surtout, le CSS est dépendant du préprocesseur choisi et difficilement évolutif.

Ce qui est mieux, c’est justement ce que nous offrent les outils de post-traitement. Aujourd’hui, on écrit du «plain CSS» et c’est tout:

.element { transition: background 1s ease; }

Notre CSS sera alors généré de la «bonne» manière qu’il soit, en fonction de plusieurs critères définis en amont. L’outil qui fait actuellement cela très bien s’appelle AutoPrefixer, et si vous n’en avez jamais entendu parler, courez vite sur leur GitHub et prenez-le en main. Il est basé sur Rework mais devrait bientôt se baser sur PostCSS. Le code généré se base sur différents paramètres:

sur le pourcentage d’utilisateurs par navigateur basé sur les données caniuse.com

sur le nombre de versions supportées d’un navigateur par rapport à la version actuelle

sur un navigateur particulier etc.

Il permet également de nettoyer le CSS en enlevant les préfixes antidatés. Autoprefixer est disponible sous un nombre incroyable de forme, que ce soit comme plugin à votre éditeur de texte (type Sublime Text), comme option d’outils d’aide à la gestion des assets comme Prepros ou Mixture, ou tout simplement comme plugin à Grunt. Personnellement, j’utilise Brunch que je trouve plus simple que Grunt, et autoprefixer-brunch avec support des source maps.

Incorporer les polyfills

La deuxième fonctionnalité envisagée, c’est l’automatisation de Polyfill. Prenons l’exemple des filtres CSS. La spécification définit le filtre flou de cette manière:

.element { filter: blur(10px); }

Sauf qu’actuellement seuls Chrome et Safari supportent cette fonctionnalité, et de manière préfixée. Pourtant Firefox permet également d’appliquer un flou sur un élément, mais en référençant un filtre SVG, de cette manière:

.element { filter: url(‘#filtre’); }

Et IE 6-9 également, via les vieux filtres DirectX:

.element { filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=10); }

Pour générer les filtres CSS de chaque navigateur, un polyfill existe. L’énorme avantage d’un postprocesseur serait ici d’automatiser cette tâche afin de ne conserver dans le CSS de travail que le code sans préfixes, et toujours future-proof.

Une autre idée pourrait être d’utiliser rework-vars, qui ajoute le support des variables CSS telles que définies dans la spécification officielle. Ainsi, notre CSS pourrait ressembler à cela:

:root { var-color: #069; } .element { color: var(color); }

Pour être compilé de cette façon (en fonction des options choisies):

:root { var-color: #069; } .element { color: #069; color: var(color); }

Idem pour calc(), nous n'aurions plus besoin de préprocesseurs pour çà.

Quels autres traitements?

Bien entendu, autre la minification, concaténation de fichiers, linters, tests, il existe d’autres petites actions que l’on pourrait effectuer en post-traitement. Par exemple, le postprocesseur PostCSS propose de vérifier que la propriété content est bien présente dès que le sélecteur contient ::after ou ::before. Au cas où il serait manquant, de le rajouter. On pourrait aussi envisager une tâche qui vérifie que le sélecteur :focus est systématiquement présent lorsque que :hover est utilisé, ou de le rajouter également, etc.

Mouais, pas sur...

Certes, tout cela est encore très récent et le partage des tâches entre préprocesseurs et postprocesseurs peu sembler obscur. Voici une image qui tente de répartir les différentes actions:

Nouveau worflow de développement CSS?

Pour moi, c’est vraiment la transparence des actions effectuées en post-traitement qui est importante, pour conserver son code le plus propre possible. J’espère avoir réussi à vous exposer mon point de vue mais je suis curieux de connaitre vos avis à ce sujet. Alors, vous en pensez quoi?

:)