Formater du CSS
Formateur CSS réindente et minifie une feuille de style dans votre navigateur. Il tokenise plutôt qu’il n’analyse, ce qui laisse passer inchangées les at-rules inconnues et les syntaxes plus récentes que l’outil — un analyseur rejette ce qu’il ne reconnaît pas, et pour un formateur, préserver quelque chose qu’il ne comprend pas vaut toujours mieux que le supprimer.
Comment fonctionne Formater du CSS ?
Formater du CSS consiste surtout à savoir où une chose commence et où elle finit, et il y a quatre endroits où la réponse naïve est fausse.
Une accolade n’est pas toujours un bloc
content: "}" contient une accolade fermante à l’intérieur d’une chaîne, et /* } */ en contient une à l’intérieur d’un commentaire. Découper sur les accolades sans suivre ces états produit un formateur qui défigure toute feuille de style contenant un compteur de pseudo-élément ou une règle mise en commentaire. L’exemple ci-dessus contient les deux, délibérément.
Un deux-points n’est pas toujours un séparateur de propriété
background: url(https://example.com/x.png) contient un deux-points à l’intérieur de la valeur, et la valeur d’une propriété personnalisée peut contenir n’importe quoi — c’est ce qui rend les propriétés personnalisées utiles. La séparation se fait au premier deux-points qui n’est pas à l’intérieur de parenthèses.
Une virgule n’est pas toujours un séparateur de sélecteurs
:is(a, b) span est un sélecteur unique contenant une virgule, et :nth-child(2n of .x, .y) en est un autre. Découper une liste de sélecteurs sur une virgule quelconque casse les deux. La séparation se fait au niveau supérieur uniquement, ce qui garde aussi rgb(0, 0, 0) intact dans une valeur.
Un tokeniseur vieillit mieux qu’un analyseur
Le CSS gagne de la syntaxe en permanence : imbrication, @container, @layer, :has(), syntaxe de couleur relative. Un analyseur doit modéliser chacune et rejette tout ce qu’il ne connaît pas, ce qui veut dire qu’il casse sur du CSS que les navigateurs acceptent déjà. Un tokeniseur n’a besoin de savoir où se trouvent les chaînes, les commentaires, les blocs et les points-virgules, et cela n’a pas changé depuis CSS 1. La syntaxe inconnue est passée telle quelle plutôt que jetée, et c’est le seul comportement responsable pour un formateur.
La minification garde un commentaire de licence
/*! … */ est la convention pour un commentaire qu’un minificateur doit préserver, et il porte en général une licence — le retirer peut en réalité enfreindre les conditions selon lesquelles la feuille de style a été distribuée. Tout le reste part. Le dernier point-virgule avant une accolade fermante part aussi, puisqu’il sépare une déclaration de rien.
Ce que la minification ici ne fait pas, c’est réécrire les valeurs : pas de raccourcissement de #ffffff en #fff, pas de fusion de règles, pas de réordonnancement. Ce sont de vrais gains, et c’est aussi là qu’un minificateur devient un compilateur avec une surface de bugs. Pour un pipeline de build, utilisez un vrai minificateur ; ceci est fait pour rendre une feuille de style assez petite à coller.
Entrée
a,b{color:red;margin:0}Formaté
a,
b {
color: red;
margin: 0;
}Quelles options et quels cas limites Formater du CSS prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Indentation | espaces | 2 | Appliqué par niveau d’imbrication, donc une règle à l’intérieur d’une media query est indentée deux fois. |
| Un sélecteur par ligne | booléen | on | Chaque sélecteur d’une liste séparée par des virgules sur sa propre ligne. Scinde au niveau supérieur uniquement, donc :is(a, b) reste intact. |
| Ligne vide entre les règles | booléen | on | Une ligne vide après chaque règle de niveau supérieur, ce qui permet de parcourir facilement une feuille de style longue. |
| Conserver les commentaires | booléen | on | Les commentaires multilignes conservent leur forme interne plutôt que d’être répartis sur plusieurs lignes, car les bannières de section en art ASCII sont courantes et les répartir les détruit. |
| Chaînes | conservées | — | content: "}" contient une accolade fermante. Le suivi de l’état des chaînes de caractères est ce qui empêche cela de mettre fin au bloc. |
| url() | consommé en entier | — | Une url() non citée peut contenir des caractères qui seraient autrement structurels, y compris deux-points et parenthèses dans un URI de données. |
| Règles @ | imbriquées | — | @media, @supports, @layer, @container et tout ce qui est plus récent. Les at-rules inconnues sont transmises plutôt que d’être supprimées. |
| Minifier | espaces uniquement | — | Réduit les espaces blancs et supprime le point-virgule final dans un bloc. Ne réécrit pas les valeurs ni ne fusionne les règles — cela relève du travail d’une étape de build, pas d’une zone de collage. |
| Commentaires de licence | /*! … */ | conservés | Préservés lors de la minification, selon la convention que suit chaque minifier. En supprimer un peut enfreindre la licence qu’il contient. |
Questions fréquentes
Va-t-il casser mon CSS imbriqué ou mes requêtes @container ?
Non, et c’est tout l’intérêt de tokeniser plutôt que d’analyser. Le formateur n’a besoin de savoir que où les chaînes, les commentaires et les blocs commencent et finissent — il n’a pas besoin de comprendre ce que signifie une at-rule. Une syntaxe plus récente que l’outil passe inchangée, ce qui est l’opposé de ce que fait un analyseur quand il rencontre quelque chose qu’il ne reconnaît pas.
Pourquoi la sortie minifiée contient-elle encore un commentaire ?
Parce qu’il commence par /*! plutôt que par /*. C’est la convention qu’honore chaque minificateur pour un commentaire qui doit survivre, et il porte presque toujours une licence — le retirer peut enfreindre les conditions selon lesquelles la feuille de style a été distribuée. Les commentaires de bloc ordinaires sont retirés.
Pourquoi la minification économise-t-elle moins qu’un vrai outil de build ?
Parce que ceci ne retire que les espaces. Un minificateur de production raccourcit aussi les couleurs, fusionne les règles dupliquées, jette les déclarations surchargées et réécrit les notations raccourcies — chacun est un gain réel, et aussi une transformation qui peut changer le comportement si elle se trompe sur un cas limite. Pour un pipeline de build, utilisez un vrai minificateur ; ceci est fait pour rendre une feuille de style assez petite à coller quelque part.
Pourquoi ma liste de sélecteurs ne s’est-elle pas séparée à chaque virgule ?
Parce que certaines de ces virgules sont à l’intérieur d’une pseudo-classe fonctionnelle. :is(.card, .panel) est un sélecteur unique qui se trouve contenir une virgule, et le séparer là produit deux sélecteurs tous deux invalides. La séparation se fait au niveau supérieur uniquement — la même règle qui garde rgb(0, 0, 0) intact dans une valeur.
Valide-t-il mon CSS ?
Non. Il formatera une feuille de style avec une propriété mal orthographiée ou une valeur invalide sans se plaindre, car un formateur qui rejetterait les propriétés inconnues rejetterait chaque préfixe vendeur et chaque nouvelle fonctionnalité. Si vous avez besoin d’une validation, les DevTools du navigateur signalent eux-mêmes les propriétés inconnues dans le panneau Styles, ce qui est un signal plus fiable que n’importe quelle liste statique.
Ma feuille de style est-elle envoyée ?
Non. La tokenisation et le formatage s’exécutent dans votre navigateur. Cela compte moins pour du CSS que pour une charge utile, mais cela compte un peu : une feuille de style d’un produit non encore publié décrit le produit, et une feuille de style d’un outil interne décrit l’outil interne.