Écrire des milliers de lignes de CSS à plat devient vite répétitif : mêmes couleurs recopiées partout, mêmes calculs de marges, aucune notion de fonction. Sass (avec sa syntaxe SCSS) ou Less répondent à ce problème en ajoutant une couche de langage au-dessus du CSS : variables, imbrication des sélecteurs, mixins, fonctions, et découpage en plusieurs fichiers réunis à la compilation. Le navigateur ne comprend pas ce langage : un outil de compilation transforme le .scss en .css standard avant publication.
Usage dans WordPress
De nombreux thèmes et extensions gardent leurs sources en .scss dans un dossier src, compilées vers build par wp-scripts build (qui embarque webpack et sass-loader) ou par Vite dans des configurations plus récentes. Depuis l’arrivée de theme.json et des variables CSS natives, une partie de ce que faisait Sass (les couleurs, les espacements) est désormais gérée nativement par WordPress, mais l’imbrication des sélecteurs et les mixins restent des atouts propres au préprocesseur.
Exemple
$couleur-accent: #2563eb;
.carte {
border: 1px solid $couleur-accent;
&:hover {
background: lighten($couleur-accent, 40%);
}
}À ne pas confondre avec
- Un postprocesseur comme PostCSS, qui transforme du CSS déjà valide (par exemple pour ajouter des préfixes vendeurs), plutôt que de compiler un autre langage.
- Les variables CSS natives (
--ma-variable), lisibles et modifiables directement dans le navigateur, contrairement aux variables Sass qui n’existent plus une fois le fichier compilé. - CSS-in-JS, qui génère du CSS depuis du JavaScript au moment du rendu plutôt qu’à la compilation d’un fichier source.