CSS depuis ses origines a toujours eu pour philosophie d’être un langage descriptif et déclaratif et non programmatif, bien que certaines fonctions comme calc() soit apparu dans les spécifications ces dernières années, son code est restée assez pure de tous langages algorithmiques.
C’est d’ailleurs bien en dépit de cette volonté qu’on vu le jour des meta langages comme SASS ou LESS afin de combler les faiblesses de son code et les redondances inhérentes à CSS. En fait grâce à son mode purement descriptif, il est resté et reste encore très lisible et accessible à tous : du webmaster, webdesigner au développeur front-end et son apprentissage est relativement aisé au regard d’un langage de programmation. C’est dans la simplicité que réside sa principale force, en revanche, le manque d’implémentation de variables est difficile à gérer sur de gros projets avec du muti-site, la création de thèmes enfants ou le moindre changement devient une tannée…

De son côté si SCSS rend bien des services aux intégrateurs, il n’est pas sans écueil dans son écriture SCSS : les variables, le nesting à outrance, les @extend et autre mixins peuvent sembler a priori abscons même pour une personne rompu à l’exercice. Et là on se dit que la simplicité de CSS peut avoir du bon pour la personne (ou pour soi-même) en charge de reprendre le code et devant le maintenir ou le faire évoluer.

Je parle ici pour ma propre expérience, notamment ou après avoir découvert les joies des préprocesseurs, je suis tombé dans le piège du nesting avec tant de niveaux de sélecteurs que j’arrivais à grand peine à retrouver les premiers parents ciblés. Peut-être que le nesting n’est pas une bonne approche même si elle est très tentante, il vaut mieux la limiter aux pseudo-classes et pseudo-éléments.

On peut penser que CSS reste très performant pour la partie structurelle du site alors pas la peine de complexifier les choses sans réelles nécessité. En outre les possibilités fonctionnelles de SCSS tel que les fonctions, les boucles… restent évidemment très pertinentes.

Souvent on est tenté de faire le match entre CSS et SCSS mais ce dernier n’a pas d’objet puisque nous pouvons avoir le meilleur des deux mondes en utilisant essentiellement, par exemple CSS dans un fichier SCSS et c’est peut-être plus ici que je vois une différence notable entre webdesigner et développeurs frond-end qui suivant leur langage de prédilection vont fournir des versions totalement différentes, parfois difficile à lire : des purs codeurs peuvent livrer des fichiers imbitables pour un webdesigner.

Alors pour ceux qui ne trouvent pas nécessaire de s’aventurer dans un langage trop algorithmique, mais qui voient bien les possibilités de travailler avec des préprocesseurs, heureusement les standards CSS évoluent, il existe désormais les propriétés personnalisées, ce sont des propriétes CSS préfixées avec deux tirets — et la fonction var (–) permet d’accéder à la valeur de ces propriétés, elles bénéficient de la cascade mais peuvent être également manipuler en js.

Ce qui est intéressant avec les custom properties c’est que le langage produit in fine est moins bavard que SCSS.

la syntaxe est la suivante :

--unecouleur: #0000ff;

Un exemple :

:root {
  --premiere-couleur: #488cff;
  --seconde-couleur: #ffff8c;
}

#premierParagraphe {
  background-color: var(--premiere-couleur);
  color: var(--seconde-couleur);
}

#secondParagraphe {
  background-color: var(--seconde-couleur);
  color: var(--premiere-couleur);
}

Ceci étant dit la question importante est de savoir si cette fonction var(–) est utilisable en production ? Pour ma part je dirais qu’on en ai pas loin l’ensemble des navigateurs ont implémentés cette fonction mais comme toujours ie ne joue pas le jeu et elle n’est supportée qu’à partir de Edge : https://caniuse.com/