L'utilisation de Tailwind CSS et de son mode Just In Time

Auparavant sur Inuit CSS, nous avons fini par rechercher un autre framework plus poussé pour plusieurs raisons, dont principalement celles-ci :

• l’absence de documentation, il faut aller fouiller dans le code dans les nodes_modules
• les outils pour flexbox et autres « nouveautés » de CSS sont limités et nous devions compléter le framework nous-mêmes

Notre choix s’est porté sur ce framework pour plusieurs raisons :

• la volonté de continuer à utiliser un langage Utility First (voir l’article à ce sujet),
• une documentation très complète et surtout très bien organisée,
• un plugin pour l’IDE Visual Studio Code qui permet une autocomplétion des classes, des warnings d’erreur de syntaxe, etc.,
• le fait que Tailwind ne soit pas un framework type « kit d’interface utilisateur », comme peut l’être Bootstrap par exemple : il n’y a aucun style par défaut et cela nous permet de totalement adapter le style à chacun de nos projets, sans avoir à surcharger du style existant.

La simplicité de configuration de chaque projet a aussi pesé dans la balance : via un simple fichier de configuration, vous pouvez configurer toutes les couleurs, les fonts (polices de caractères), les tailles d’écran, etc. Sans compter la possibilité de créer de nouvelles classes utilitaires au besoin, tout en ayant toujours la possibilité de conserver son propre code CSS sur mesure pour certains composants, comme les boutons par exemple.

Tailwind CSS offre un très large choix de classes utilitaires, ce qui ouvre énormément de possibilités de personnalisation sans avoir à créer de nouvelles classes CSS. Les couleurs, les paddings, margins, tailles, et d’autres classes, sont de plus déclinées dans plusieurs variantes disponibles :

• tailles d’écran pour le responsive
• hover
• focus
• active
• …

C’est un gros avantage, notamment pour la rapidité du développement, mais cela implique aussi un inconvénient de taille : le poids du fichier CSS final. D’autant qu’à chaque mise à jour de Tailwind, de nouvelles classes utilitaires sont créées, ainsi que de nouvelles variantes.

Pour éviter de se retrouver avec un fichier CSS beaucoup trop lourd et plein de classes inutilisées, Tailwind propose jusqu’à sa version 2 un guide pour réduire le nombre de classes générées : ceci passe par une définition précise de votre palette de couleurs, la limitation des variantes pour chaque type d’utilitaire, etc. Cependant, pour vraiment alléger le fichier, l’utilisation de PurgeCSS est préconisée jusqu’à la v2 de Tailwind.

PurgeCSS est un outil qui va supprimer les classes CSS inutilisées du fichier de style en production. Il est vraiment utile lorsque vous utilisez justement un framework CSS comme TailwindCSS, Bootstrap, MaterializeCSS, Foundation, etc… Comme nous l’expliquions plus tôt, en utilisant ce type de frameworks, vous n’utiliserez que quelques classes parmi la multitude à disposition, et de nombreuses classes CSS inutilisées seront incluses dans votre fichier de style final.

C’est là que PurgeCSS entre en jeu. L’outil va analyser vos fichiers de templates (vous aurez à renseigner le chemin des fichiers à observer) et vos fichiers CSS, va faire correspondre les sélecteurs utilisés dans vos fichiers de style avec ceux de vos templates, puis il va supprimer les sélecteurs inutilisés du fichier CSS compilé. Vous obtenez donc un fichier final beaucoup plus allégé, avec uniquement les sélecteurs que vous utilisez réellement.

Dans un projet sur mesure (Rails, Symfony…), cette solution est donc totalement adaptée, à condition de bien lister l’intégralité des templates.

Malheureusement, pour nos projets WordPress avec le système de gestion de contenu que nous avons mis en place, PurgeCSS devient trop lourd à gérer. Il nous faudrait whitelister non seulement toutes les classes que l’utilisateur du site pourrait entrer dans les composants, mais aussi toutes celles utilisées par défaut dans le fonctionnement des composants.

Jusqu’à l’arrivée du mode Just in Time dans la version 2 de Tailwind CSS, nous devions donc filtrer, via le fichier de configuration de Tailwind, toutes les classes utilitaires et les variantes dont nous avions réellement besoin. Il fallait rester vigilant lors du développement pour ajouter les bonnes classes utilitaires ainsi que les variantes uniquement nécessaires, au risque de surcharger le code inutilement.

À partir de la v2.1 de Tailwind, il a été possible de mettre en place le mode Just In Time, encore en preview à ce moment là. Aujourd’hui, dans la v3, ce mode est devenu le moteur du framework et change totalement l’utilisation et la façon de développer avec Tailwind.

Le Just In Time est une nouvelle façon de compiler le CSS. Grâce à ce mode, plutôt que d’avoir un CSS compilé et généré par avance avec tout le contenu du framework puis nettoyé avec PurgeCSS, les fichiers de template (et tout autre fichier que vous aurez indiqué) sont observés par Tailwind et le CSS est généré uniquement en fonction des classes qui y sont présentes.

Le principal avantage de ce mode est la réduction du poids du fichier de style final, sans avoir à se préoccuper de filtrer soi-même les classes à utiliser, mais ce n’est pas tout :

• L’intégralité des classes CSS du framework est maintenant disponible avec toutes les variantes. Auparavant, certaines variantes n’étaient pas activées par défaut pour ne pas surcharger le fichier de style de base généré par Tailwind. Étant donné que le mode JIT génère le CSS à la demande, vous pouvez utiliser n’importe quelle variante sur n’importe quelle classe utilitaire. Il est même possible de les empiler : par exemple si vous souhaitez qu’en dark-mode, à partir du breadcrumb « lap », le background soit de couleur rouge au hover, vous pouvez écrire dark:lap:hover:bg-red-600.
• Il est possible de générer du style de façon arbitraire, sans avoir à utiliser des valeurs déjà présentes dans la bibliothèque de Tailwind. Ainsi, si exceptionnellement vous avez besoin d’une hauteur spécifique, vous pouvez écrire h-[75px]. Ces valeurs sont également utilisables avec n’importe quelle variante.
• Le code sera identique en production et en développement puisqu’il est généré en fonction des classes utilisées. Ce qui ajoute un autre avantage pour le développement, puisque le CSS y sera aussi léger à charger qu’en production.

L’inconvénient principal que nous avons relevé sur Tailwind après tout ce temps est toujours vis-à-vis de l’utilisation avec WordPress.

Comme dit précédemment, notre plugin de gestion de contenu, le Flexible Contents, laisse la possibilité à l’utilisateur d’entrer des classes CSS pour personnaliser certains blocs (couleur, ajout de marges, titre centré…). À la compilation, ces classes ne seront pas vues par le framework puisqu’elles sont entrées en base de données et non dans le code d’un template, et il ne les génèrera donc pas dans le style si elles ne sont pas déjà appelés dans les templates.

Mais là encore, il existe une solution native dans le framework : les développeurs de Tailwind ont mis en place une liste d’exceptions ou safelist, utilisant des patterns en expression régulière pour s’assurer de la présence des classes dans le CSS final.

Par exemple, ajoutez un { pattern: /^m-/, variants: [ 'lap', 'md', 'desk', 'wall', 'wide'] }, dans cette safelist, et toutes les valeurs de margin sont incluses, présentes ou non dans les template, et ce pour chaque variante de breakpoint.

Bien évidemment, cela demande un peu de maintenance sur les projets, si l’utilisateur est amené à utiliser des classes bien spécifiques. Néanmoins, après étude des différents projets, nous avons pu en retirer une liste de classes habituellement utilisées et ainsi couvrir 99% des cas.

Un autre inconvénient serait le fait d’avoir un HTML qui devient très dense avec toutes ces classes. Néanmoins, dans l’équipe nous avons pris l’habitude maintenant de le lire de cette façon, et finalement cet inconvénient se tourne plutôt en avantage pour qui sait lire le Tailwind : vous n’avez plus besoin de chercher dans votre/vos fichier(s) CSS où est stylisé ce bloc, vous avez tout sous les yeux directement.

Après tout ce temps passé à utiliser Tailwind CSS pour nos projets sur mesure ou WordPress, et en ayant suivi son évolution, nous ne reviendrions pas en arrière. Ce framework est complet, extrêmement bien documenté, son équipe de développeurs est active et le framework est constamment mis à jour pour offrir toujours davantage de possibilités de personnalisation et accroître ses performances.

Grâce à lui, nous pouvons proposer des sites totalement personnalisés à la charte du client, sans avoir à changer de framework, ou surcharger du style existant. Un simple fichier de configuration permet de spécifier la charte graphique globale, et le reste se fait dans l’intégration du DOM.

Si vous ne l’avez pas encore essayé, c’est le moment : tailwindcss.com.