Résumé

  • Le premier projet public CSS Variables du W3C, daté du 10 avril 2012, partait des valeurs répétées dans les feuilles de style. Il proposait des noms comme var-color, lus par var(color), et laissait la cascade décider de la valeur propre à chaque élément.
  • Le texte candidat du 3 décembre 2015 employait --main-color et var(--main-color). Le texte candidat du 16 juin 2022 précisait les valeurs de secours et les références manquantes ou circulaires. Une couleur commune pouvait descendre dans l’arbre tandis qu’un composant choisissait la sienne.

Le chef de la rédaction a demandé un bordeaux moins sévère. Le problème n’était pas de trouver une nuance : il fallait retrouver tous les endroits où l’ancienne avait élu domicile. Un bouton, trois liens, un bandeau et un titre oublié depuis la dernière refonte portaient chacun leur propre copie. Corriger trente fois la même valeur invitait à manquer la trente et unième. Les variables CSS ont proposé un meilleur facteur : écrire la couleur une fois, lui donner un nom, et laisser les éléments demander ce nom.

Le premier projet public CSS Variables publié par le W3C le 10 avril 2012 formulait exactement ce souci. Une grande feuille de style répète des couleurs et d’autres valeurs; un remplacement de texte peut toucher trop de choses ou en oublier. Le projet permettait à l’auteur de définir une propriété portant un nom choisi, puis d’utiliser sa valeur ailleurs. L’exemple plaçait une couleur près de la racine du document. Ses descendants la recevaient suivant les règles ordinaires de CSS. Le courrier passait par la cascade, avec ses adresses et ses priorités, pas par une recherche aveugle dans les fichiers.

Le langage de 2012 mérite sa propre étiquette historique. Il écrivait var-color et appelait var(color). Le projet montrait une valeur à la racine, une autre sur un div, puis une troisième sur un élément d’alerte. Plusieurs couleurs pouvaient donc cohabiter sous le même nom selon l’endroit où se trouvait l’élément. La direction envoyait une note générale; une équipe locale pouvait afficher une consigne différente sur sa porte. Cette souplesse donnait à la variable sa portée réelle.

Des noms peuvent aussi se renvoyer la balle sans fin. Le projet décrivait deux variables qui se réfèrent mutuellement et deviennent invalides. À la question « quelle couleur choisir ? », chacune répond « demande à l’autre ». Le navigateur ne découvre pas une couleur cachée au terme du cercle : il applique les règles de calcul des valeurs et la déclaration qui dépend du cercle en subit l’effet. La commodité d’un nom partagé s’accompagne d’un graphe de dépendances qu’il faut savoir lire.

Dans la recommandation candidate du W3C du 3 décembre 2015, la graphie familière était en place. La propriété personnalisée s’écrivait --main-color; les autres règles lisaient var(--main-color). Le texte plaçait une couleur principale à la racine et l’utilisait aussi dans un fond d’accent dérivé. Quand la valeur nommée changeait, les usages qui en dépendaient suivaient. La rédaction pouvait modifier son bordeaux sans fouiller chaque bouton comme un tiroir d’archives.

Encore fallait-il savoir à qui la note parvenait. Un composant qui définit son propre --main-color donne à ses descendants une valeur locale. Le site peut rester bordeaux tandis que le panneau des abonnés devient turquoise. Pour comprendre une couleur surprenante, chercher la première occurrence du nom ne suffit pas : il faut examiner la déclaration qui l’emporte pour cet élément, avec l’héritage et les règles locales. La cascade n’était pas un tuyau central; c’était un système d’adresses où le courrier le plus pertinent arrivait au bon bureau.

Le texte candidat du W3C du 16 juin 2022 expliquait comment un composant pouvait rester présentable quand aucune couleur ne lui avait été envoyée. Dans var(--header-color, blue), le second argument fournit une valeur de secours. Un composant réutilisable garde ainsi un choix par défaut tout en acceptant que l’application hôte fournisse le sien. Le texte précise que cette valeur peut contenir des virgules : tout ce qui suit la première virgule séparatrice appartient à la solution de secours. Le composant apporte sa propre veste, mais accepte celle de la maison.

Les valeurs manquantes et les références circulaires se règlent lors du calcul de la valeur. Une déclaration contenant var() peut sembler correcte lorsque la feuille est lue; la substitution révèle ensuite que la valeur demandée manque ou boucle. Une valeur de secours utilisable évite alors la panne de couleur; sans elle, la déclaration dépendante perd le résultat prévu. À l’écran, le diagnostic est concret : l’élément a-t-il hérité du nom général, reçu une variante locale, utilisé son secours ou perdu une déclaration ? La réponse se trouve dans le style calculé de cet élément.

Les dates montrent aussi que l’orthographe a changé. Le projet de 2012 parlait var-color et var(color). La recommandation candidate de 2015 employait --main-color et var(--main-color). Le texte candidat de 2022 affinait la gestion des secours et des valeurs invalides. Mélanger ces trois instantanés ferait passer une ancienne forme pour une instruction actuelle. L’idée qui traverse les versions est plus solide que la ponctuation : nommer une valeur, la laisser suivre la cascade, puis accepter les exceptions du lieu où elle arrive.

La rédaction peut désormais décider où commence et où s’arrête la couleur commune. Le bordeaux de la racine unit les pages. Le panneau turquoise répond pour sa propre branche. Un module invité garde une valeur de secours dans sa poche. Le navigateur distribue les valeurs et calcule le résultat; l’éditeur juge si ces exceptions composent encore une identité visuelle. Les boutons, eux, ne peuvent plus dire qu’ils n’ont jamais reçu la note.