Préprocesseur CSS
SCSS, Less et Stylus en CSS

Ce que fait un préprocesseur CSS

Une feuille de styles avec de l'imbrication n'est pas du CSS valide. Le navigateur abandonne la règle entière et ne dit rien. Par conséquent, ce préprocesseur CSS aplatit l'imbrication, remplace les variables par leurs valeurs et écrit le CSS à plat qu'un navigateur peut lire.

D'un seul collage reviennent trois choses. D'abord le CSS compilé lui-même, prêt à coller dans un fichier. Ensuite une liste des variables et des mixins trouvés, avec la valeur que chacun porte. Enfin un panneau de notes qui nomme tout ce que le compilateur a dû décider seul.

Ce dernier panneau compte plus qu'il n'y paraît. Une supposition silencieuse dans du CSS compilé est une mise en page cassée deux écrans plus loin. Donc chaque hypothèse est imprimée à côté de la sortie plutôt qu'enterrée dedans.

Le convertisseur travaille aussi à l'envers. Parce qu'un fichier à plat est difficile à garder en ordre, il peut regrouper du CSS ordinaire en SCSS ou Less imbriqué, avec les valeurs communes sorties comme variables. Vous n'installez rien et vous n'envoyez rien.

Comment un préprocesseur compile vers du CSS

Le travail se fait en trois passes. D'abord, le lecteur transforme la source en une liste de règles, chacune avec un sélecteur, un bloc et une profondeur. Ensuite une deuxième passe relie les sélecteurs imbriqués à leurs parents. Enfin un écrivain imprime les règles à plat dans l'ordre.

Relier les sélecteurs suit les règles de sélecteurs que le navigateur utilise lui-même. Une règle imbriquée une fois devient un sélecteur descendant. Une règle écrite avec une esperluette garde son parent attaché, et c'est ainsi qu'on construit un état hover et une classe modificatrice.

Les variables sont le deuxième travail. Parce que SCSS et Less permettent tous deux qu'un nom tienne lieu de valeur, le compilateur cherche chaque nom qu'il rencontre et écrit la valeur à sa place. Les variables Sass commencent par un signe dollar, et les variables Less par un arobase, donc le lecteur les distingue au premier caractère.

L'écrivain ne touche jamais à une API du navigateur et jamais au réseau. Donc la page fonctionne hors ligne. Elle fonctionne aussi sur un fichier que vous préférez ne pas coller dans un compilateur hébergé, comme une feuille de styles qui nomme un produit non annoncé.

SCSS, Less et Stylus côte à côte

Les trois langages s'accordent sur l'idée et diffèrent sur la ponctuation. Donc le compilateur lit les trois et écrit une seule sortie.

Le SCSS garde les accolades et les points-virgules du CSS, et c'est pourquoi il ressemble à du CSS avec des fonctions en plus. Le Less fait de même, et il autorise en plus un appel partiel de mixin sans parenthèses. Le Stylus laisse tomber les accolades, les points-virgules et souvent les deux-points, et s'appuie sur l'indentation à la place.

Parce que les différences sont petites, une seule page peut lire les trois. Le lecteur décide du langage qu'il a sous les yeux en regardant le fichier : un signe dollar pointe vers le SCSS, un arobase devant un nom pointe vers le Less, et une accolade absente pointe vers le Stylus. Quand la source est ambiguë, la page le dit dans le panneau de notes au lieu de deviner.

La sortie est la même dans tous les cas. Donc le navigateur voit une seule feuille de styles à plat, et vous gardez la source dans le langage que votre équipe utilise déjà.

Pourquoi relier les sélecteurs est la partie difficile

Un compilateur qui colle les deux sélecteurs avec une espace rate la plupart des imbrications. Parce qu'une règle imbriquée sous un parent ne devient un descendant que sans esperluette, le lecteur suit la trace du parent à chaque niveau en descendant.

Donc chaque bloc garde le sélecteur complet qu'il imprimera. Une règle tout en haut commence par son propre sélecteur. Ensuite une règle à l'intérieur hérite de celui-là et ajoute le sien, séparés par une espace. Une esperluette remplace l'espace entièrement, et c'est ainsi que l'état hover d'un parent s'attache sans trou.

L'ordre des règles imprimées est le troisième cas. Parce qu'une règle plus tardive de même poids l'emporte, l'écrivain garde l'ordre de la source à chaque niveau. De cette façon la cascade survit à la compilation, et une règle que vous vouliez gagnante gagne encore.

Ce qui compile proprement et ce qui reçoit une note

Un compilateur gagne la confiance en nommant ses propres limites. Par conséquent, le panneau de notes liste chaque construction que le lecteur a traitée d'une façon que vous devriez vérifier.

Les définitions et les inclusions de mixins compilent, parce que les deux langages les définissent dans la source que vous avez collée. Les expressions de garde du Less compilent quand la condition est une comparaison simple. Donc un mixin gardé insère la branche qui correspond.

L'interpolation reçoit une note plus souvent. Parce qu'une valeur construite à partir d'une variable dans une chaîne a besoin de la valeur au moment de la compilation, le lecteur ne peut la résoudre que si la variable est dans le même fichier. Une valeur qui vient d'un import que la page n'a pas reste telle qu'écrite, et la note dit quel nom manquait.

Les imports eux-mêmes reçoivent aussi une note. La page ne peut pas récupérer un autre fichier, puisqu'elle ne touche jamais au réseau. Donc un at-import reste dans la sortie comme un import CSS ordinaire, et le panneau dit que le fichier n'a pas été lu. Cela garde la sortie honnête plutôt que silencieusement fausse.

Le comptage à côté de la sortie fait partie de la même idée. Parce qu'une compilation peut changer la taille d'un fichier dans les deux sens, le panneau indique les règles écrites, les déclarations qu'elles contiennent, et la taille de l'entrée et de la sortie. Donc une feuille de styles qui a grossi après compilation se voit d'un coup d'œil et non après un déploiement.