• WeShare

À la découverte des préprocesseurs CSS

WeShare

À la découverte des préprocesseurs CSS

 

À la découverte des préprocesseurs CSS

Mais qu’est-ce qu’un préprocesseur ?

Pourquoi les utiliser ?

Thématiser avec les variables

L’imbrication de règles (nested rules)

L’import des feuilles de style

Mixin et include

Les extensions de styles

Les partials

La compilation Sass

Utiliser Bootstrap avec Sass

Téléchargement des sources

Création des fichiers utilitaires

Création d’un fichier de personnalisation de bootstrap

Création d’un fichier gestionnaire d’imports

Création d’un fichier pour chaque page du site

Conclusion et remarques en vrac

Webthèque

Articles Sass

Articles sur l’optimisation / bonnes pratiques web (axés sur les perfs)

Les risques d’utiliser un préprocesseur

 

 

Cet article a pour objectif de présenter les préprocesseurs CSS, et de vous inviter à plus largement les utiliser en découvrant les nombreux avantages qu’ils présentent.

Le niveau de cet article est simple, mais conviendra surtout aux développeurs / intégrateurs, qui n’ont pas encore sauté le pas et qui ont des besoins élevés / récurrents en termes de design.

Cet article se fonde sur mon expérience (2020 : +3 ans de dev avec Sass), tout en s’appuyant sur des sources que vous retrouverez en fin d’article. Aucune prétention à expliquer « comment » les utiliser, ou « quelle est la meilleure façon de faire ». Il est plutôt question d’une découverte répondant au « Pourquoi » les utiliser, en présentant ma façon de faire.

L’article n’a pas non plus vocation à présenter toutes les fonctionnalités des préprocesseurs, les documentations officielles ou autres tuto internet sont déjà suffisamment fournis.

Mais qu’est-ce qu’un préprocesseur ?

Un préprocesseur est un programme qui interprète du code sous un certain format pour en générer un autre sous un autre format. Dans notre cas, nous allons parler des préprocesseurs CSS en ne citant que les plus utilisés : LESS et Sass.

Nous nous concentrerons alors sur la découverte de Sass, avec en bonus : une mise en pratique avec l’intégration d’un framework dont il est nul besoin de présenter, j’ai nommé… Bootstrap 😊

Pourquoi les utiliser ?

Grâce à ce genre d’outils, on peut booster nos performances frontend et ainsi se focaliser sur d’autres tâches à plus forte valeur ajoutée, centrée sur les problématiques métiers.

Conditions d’usages
  • C’est un nouveau langage à apprendre.
  • Il peut être parfois plus complexe à lire ce qui rend la chose plus difficile à saisir que lorsqu’on lit du CSS pur. Bien penser à utiliser le flag –sourcemap à la compilation pour faciliter l’inspection.
  • Il nécessite de nouveaux outils / programmes, relativement simple d’usage, afin de compiler votre code en un code interprétable par vos navigateurs.
  • Requiert de solides connaissances de CSS.
Avantages

Premièrement, notre code sera mieux structuré, et mieux découpé. Et donc plus facilement maintenable et évolutif. De plus, il est complètement interopérable avec CSS.

Et ses fonctionnalités alors ?

  • Utilisation de variables pour réutiliser les concepts (couleurs, espacements, tailles, etc.)
  • Imbrication des règles pour créer des « modules »
  • @import pour combiner des feuilles de style Sass et CSS, fournissant l’accès aux variables, mixins et fonctions
  • @mixin et @include pour hériter / réutiliser des règles
  • @extend pour appliquer une règle à une autre
  • Les partials pour stocker du code qui ne sera compilé que s’il est importé dans d’autres fichiers

Le mot d’ordre ? DRY : Don’t Repeat Yourself ! L’arnaque, c’était un acronyme…

Il n’est pas nécessaire de connaître toutes les fonctionnalités offertes par Sass. Il suffit d’en piocher quelques-unes, les expérimenter, évoluer par étape, et identifier celles qui nous feront gagner du temps.

Thématiser avec les variables

Tel que nous le ferions en CSS pur, Sass permet la déclaration de variables. Avec ou sans préprocesseurs, les variables (ou propriétés personnalisées) permettent de stocker des valeurs de façon sémantiques, afin de les appliquer de part et d’autre des feuilles de styles.

En résulte un gain en lisibilité, facilitant ainsi la maintenance et l’évolution des thèmes, si tant est que nous déclarions judicieusement nos variables, de manière générique.

 

_custom_variables.scss

_header.scss

Résultat

Ainsi, nous pourrions intégrer le thème conçu pour le site A au site B, en modifiant simplement quelques propriétés au lieu de les chercher fastidieusement à travers tout le code.

L’imbrication de règles (nested rules)

L’imbrication de règles CSS permet une meilleure lecture de nos styles dépendants d’un élément englobant. Ce système permet d’intervenir rapidement sur un « module » ou « composant » HTML, de l’éditer, le partager, ou le réutiliser à travers nos projets.

A l’usage, la bonne pratique recommande de ne pas dépasser 3 niveaux d’imbrication.

_header.scss

Notez l’utilisation intuitive du sélecteur & appelé « sélecteur de parent » en Sass.

Notez également l’utilisation de la fonction Sass ‘darken’ qui prend en compte ces paramètres : une couleur, ainsi qu’un pourcentage pour obscurcir ladite couleur.

Résultat CSS après compilation

Dans l’exemple ci-dessus, on remarque rapidement que ces styles appliqués aux boutons et liens ne seront effectifs que s’ils sont présents dans la balise html <header>…</header>.

L’import des feuilles de style

Reprenons l’exemple précédent au sujet de l’imbrication de règles. En effet, celui-ci utilise des variables déclarées dans un autre fichier. Il faut donc importer le fichier où ces variables sont définies avant de pouvoir les utiliser.

L’import explicite

_header.scss

L’import est explicite, les variables sont directement accessibles dans le fichier _header.scss

L’import implicite

_common.scss

Ici, nous avons un fichier _common.scss qui se charge d’organiser nos imports, tous les styles communs à chacune des pages de notre site.

Ainsi, on importe les variables et le header dans ce fichier, mais les variables sont également accessibles dans le fichier _header.scss.

Mixin et include

Les mixins permettent de définir des règles réutilisables et paramétrables. Pour donner un exemple concret, au lieu d’utiliser autoprefixer afin de régler la compatibilité avec les vieux navigateurs, il est possible d’utiliser ce genre de mixin :

 

_custom_mixins.scss

Notez l’utilisation de ($params…) qui permet de chaîner les paramètres. Ici nous animons les bordures de l’élément l’effet ‘border-dance’, mais nous pourrions rajouter une animation sur le texte par exemple, en séparant d’une virgule chaque effet avec leurs propriétés d’animation.

index.scss

Résultat

Ainsi, la règle sera appliquée pour chaque préfixe vendeur.

Les extensions de styles

Sass offre également un système d’héritage qui permet de définir une classe avec ses propres styles, tout en incluant les styles d’une autre classe. Le résultat est proche des mixins, au détail près que les extensions sont utilisées sans paramètres, comme copier-coller le code d’une classe dans une autre.

_tables.scss

Résultat

template_table.html

Ici, on déclare une classe table-bordered qui va définir les bordures de notre élément. Ensuite, pour chaque élément enfant td et th, on réapplique le même style en faisant un @extend du parent, pour que chaque ligne et colonne aient une bordure. En revanche, on modifie la couleur des bords.

Ce n’est pas le meilleur exemple stylistique, mais il illustre bien les possibilités offertes par l’extension.

Les partials

Les fichiers préfixés d’un « _ » sont appelés partials. De cette manière, on explique au compilateur Sass de ne pas compiler ces fichiers. Ceux-ci sont alors destinés à être importé par d’autres fichiers sass (non préfixés), qui eux, seront compilés avec toutes leurs dépendances.

L’idée, c’est de modulariser notre code, et faire en sorte qu’une page web n’inclut qu’une seule feuille de style CSS, elle-même générée grâce à plusieurs feuilles de styles bien découpées.

Ainsi on diminue le nombre de requêtes pour obtenir les ressources nécessaires au chargement de chaque page, ce qui participe à l’amélioration du temps de réponse.
Attention, fournir un seul fichier CSS n’est pas une recette miracle, il existe plusieurs bonnes pratiques à combiner pour optimiser le temps de chargement d’un site web.

La compilation Sass

La compilation Sass va réorganiser le code généré, le factoriser, supprimer les doublons, regrouper les règles qui peuvent l’être etc.

Sass permet donc de générer du code CSS selon plusieurs styles de sorties :

  • Développement
    • Nested – par défaut
    • Expanded
  • Production
    • Compact
    • Compressed

En développement et pour faciliter le debug de nos règles CSS, le style expanded sera le plus convenable. En effet, lorsque nous inspectons notre code CSS généré, ce mode de compilation facilite la lecture.
Le mieux en outre, lors de la compilation de nos fichiers est de générer le source map avec son fichier CSS grâce au flag –sourcemap. Ainsi nous verrons dans quel fichier scss, et sur quelle ligne se situe la règle que nous inspectons dans notre navigateur.

 

En revanche, en production, il est préférable de générer des fichiers qui prennent le moins d’espace possible, et ainsi grapiller quelques optimisations de stockage et délai de chargements, avec le style compressed.

Plusieurs méthodes sont disponibles pour compiler avec Sass. Soit par l’utilisation d’un outils tiers (avec interface graphique ou non), soit en ligne de commande.

 

Utiliser Bootstrap avec Sass

Porté depuis Less vers Sass depuis la version 3, et livré avec les sources Sass depuis la version 4, Bootstrap offre des possibilités d’intégration et personnalisation bien plus souples.

Désormais, pour chaque projet web embarquant Bootstrap, mettons en place cette petite routine :

  • Téléchargement des sources et dépendances
  • Création des fichiers utilitaires
    • Variables
    • Polices de caractères et icones
    • Mixins
  • Création d’un fichier de personnalisation de bootstrap
  • Création d’un fichier qui organise les imports
  • Création d’un fichier pour chaque page du site

Effectivement on passe un peu plus de temps à mettre en place cette routine plutôt que d’inclure les fichiers CSS par un CDN. En revanche, une fois ce travail réalisé et maîtrisé, les autres fois seront bien plus rapides grâce aux fragments de codes (snippets) que nous pourrons réutiliser à travers n’importe quel projet.

Téléchargement des sources

Là où nous utilisions des CDN (Content Delivery Network), ou les fichiers CSS compilés distribués par Bootstrap, nous utilisons désormais directement les sources Sass afin de sélectionner les composants.

Ainsi, il suffit de :

  • Télécharger l’archive et extraire les sources dans le dossier de notre choix
  • Ou télécharger les sources via un package manager (npm dans mon cas)

Ensuite, ces sources seront accessibles dans nos propres feuilles de styles par chemin relatifs.

Création des fichiers utilitaires

Ces fichiers représentent l’identité de la marque, la base de notre thème.

Dans mon cas, je récupère toujours la même base :

  1. Un fichier de variables, où nous allons modifier les couleurs selon la charte graphique imposée par le client, ou en récupérant les couleurs de son logo ou de ses supports de communication.
  2. Un fichier pour les polices et icones (exemples):
    1. Polices : Roboto
    2. Icones : Fontawesome ou Material Icons
  3. Un fichier avec nos mixins

A noter que Bootstrap vient accompagné du même genre de fichiers utilitaires dont on peut se servir ou s’inspirer. Il est donc tout à fait possible d’utiliser les variables ou mixins de Bootstrap :

Ou même de les outrepasser (override) en définissant des variables / mixins portant le même nom.

Création d’un fichier de personnalisation de bootstrap

A mon sens, c’est à cette étape que l’on profite au mieux de la puissance de Sass. En effet, qu’importe le projet, nous n’aurons certainement pas besoin de tous les composants bootstrap. En tout cas, pas sur toutes les pages.

Ici, le plus gros travail est d’identifier en amont quels sont les composants les plus communs, et lesquels sont utilisés de manière plus ponctuelle. Par conséquent, il est nécessaire de bien maîtriser Bootstrap, et pourquoi pas analyser tous ses fichiers scss.

Voici le snippet que nous allons utiliser :

_custom_bootstrap.scss

Tout se passe dans le répertoire bootstrap/scss.

Remarquez qu’il est également possible d’importer la totalité de bootstrap, je vous invite d’ailleurs à aller voir ce fichier scss bootstrap/scss/bootstrap.

Vous remarquerez ainsi que je me suis inspiré de ce fichier pour construire le mien. En effet, et je l’ai découpé en plusieurs régions :

  • Fichiers requis
  • Styles généraux (optionnels) mais quand-même bien pratiques !
  • Eléments communs à quasiment toutes les pages
  • Eléments plus ponctuels

Et ce sont surtout ces derniers qui vont nous intéresser. L’idée, c’est qu’on va pouvoir effectuer ces imports uniquement lorsqu’une page en a besoin. Cela permet de générer moins de code inutile pour chacune des pages, cool n’est-ce pas ?

Création d’un fichier gestionnaire d’imports

Maintenant que l’on possède tous les fichiers utilitaires ainsi que la personnalisation fondamentale de bootstrap, nous allons créer un fichier qui va gérer nos imports.

Evidemment, nous voulons avoir accès à nos variables et mixins depuis chacun de nos fichiers scss, ce code ne sert qu’au compilateur Sass pour récupérer des instructions, en les appliquant là où se situe le besoin.
De même pour les polices de caractères et les polices d’icônes, que l’on souhaite rendre accessibles à travers la totalité du site.

_common.scss

Encore un fichier partial, puisque ce « loader », ou gestionnaire d’imports va lui-même être importé pour chaque fichier associé à une unique page du site 😊.

J’y ai mis le strict minimum, mais nous pourrions y ajouter d’autres styles qui seront communs à chaque page du site :

  • scss
  • scss
  • scss
  • scss

Création d’un fichier pour chaque page du site

Prenons l’exemple d’un site de club sportif. Nous avons plusieurs pages :

  • Authentification
  • Accueil
  • L’équipe
  • Les joueurs
  • Les résultats
  • A propos

 

home.scss

players.scss

results.scss

 

Remarques :

Chaque fichier importe _common.scss, le contenu de chaque fichier du gestionnaire d’imports va être inséré au début de chacune de nos pages uniques, ainsi les fichiers générés (home.css, player.css, et results.css) contiendront une base commune, avec en plus leurs spécificités uniques telles que le composant tables, ou list-group…

L’inconvénient d’un point de vue stockage, c’est qu’on a du code dupliqué dans une multitude de fichiers (css générés) à mesure que l’application grossit. L’avantage pour le navigateur est qu’il n’a qu’un seul fichier à requêter au serveur par page.

Ces fichiers ne sont pas des partials, en effet, nous avons besoin que Sass génère les fichiers CSS correspondant, contrairement aux fichiers communs qui eux ne sont voués qu’à être importés par d’autres fichiers scss pour la compilation.

Conclusion et remarques en vrac

Les préprocesseurs offrent de nombreux avantages, mais nous pourrions nous y perdre ! Faites comme moi, piochez quelques fonctionnalités, expérimentez-les étape par étape, et à mesure que celles-ci deviennent des automatismes, découvrez-en davantage.

N’ajoutez plus vos fichiers CSS à vos dépôts de sources, il faudra un peu de travail DevOps pour générer les CSS en production, mais vous gagnerez du temps en relecture de vos diffs, et sur le contrôle des sources.

Soyez généreux avec les commentaires, ceux-ci seront ignorés à la génération 😊

N’oubliez pas le flag –sourcemap à la compilation !

Soyez judicieux avec votre sémantique, variables et découpage/nommage de vos fichiers, pour ainsi permettre une meilleure collaboration en équipe.

Merci de m’avoir lu jusqu’au bout, j’espère avoir donné l’envie à certains de creuser le sujet 😉

 

Webthèque

 

Articles Sass

Site officiel de Sass

Préprocesseurs présentés par Alsacréation

Bootstrap theming with sass

Sass Tricks (Anglais)

Les styles d’affichage des fichiers css générés par Sass (Anglais)

Sass compilation et outils disponibles

 

Articles sur l’optimisation / bonnes pratiques web (axés sur les perfs)

https://audreytips.com/optimiser-site-web/

https://lehollandaisvolant.net/tuto/pagespd/

https://gaelbillon.com/comment-optimiser-le-temps-de-chargement-dun-site-web

 

Les risques d’utiliser un préprocesseur (~2013) :

https://iamvdo.me/blog/pourquoi-je-nutilise-pas-les-preprocesseurs-css

https://www.nicolas-hoffmann.net/source/1535-Preprocesseurs-mais-c-est-de-la-CSS-au-fait.html

https://www.hteumeuleu.fr/un-pre-processeur-est-un-outil/