Utiliser if dans du... CSS
Le CSS n'en finit plus de se transformer et d'incorporer de nouvelles fonctionnalités qui requéraient auparavant de passer par des pré-processeurs type Sass ou Less.
C'est encore le cas avec l'arrivée de la très attendue (et inespérée !) fonction if() qui permet d'exprimer directement dans notre feuille de style une logique conditionnelle sans les moyens détournés habituels : media ou container queries, sélecteurs d'attributs ou fonctions css calc() et clamp().
Prenons un cas d'usage assez banal avec ces badges reflétant un statut :
Sans if()
Jusqu'à présent, j'avais pour habitude de créer des variables CSS pour contrôler les propriétés qui m'intéressent (border, background-color) et d'en modifier ensuite les valeurs dans chaque sous-sélecteur de type [data-status="XXX"]. Ce qui donnait :
L'inconvénient de cette approche est que la logique conditionnelle ne ressort pas explicitement au premier coup d'oeil. Surtout elle reste très verbeuse puisqu'elle nécessite plusieurs sélecteurs CSS afin de cibler tous les états possibles du badge.
Avec if()
Grâce à cette nouvelle fonction if(), on peut dorénavant centraliser toutes ces variations au sein d'un même sélecteur !
On commence par définir une variable CSS custom --status qui récupère automatiquement la valeur de [data-status] à l'aide de la fonction attr() :
Puis on appelle la fonction if() pour tester différentes valeurs de --status :
Certes il aurait été plus intuitif d'écrire --status == pending mais la bonne syntaxe est bien style(--status: pending).
Quelle que soit la condition testée, la syntaxe générale du if() en css restera la même :
property : if(condition1: value; condition2: value; ... else: value);
Au final, c'est un poil moins long 🤏 et surtout bien plus clair dans l'intention.
Compatibilité avec les navigateurs
Comme souvent, c'est Chrome qui a pris les devants en termes de support en embarquant le if() dès la version 137 (sortie fin mai 2025). La plupart des autres navigateurs non basés sur Chromium sont encore aux fraises sur le sujet, la prudence reste de mise avant d'envoyer ça en production.
Est-ce une si bonne idée ?
Plutôt, dans la mesure où on peut régler de façon bien plus élégante et maintenable certains problèmes traditionnels de layout et de style.
L'exemple proposé par Una Kravets pour classer des tickets dans différentes colonnes est particulièrement ingénieux et permet bien de sentir l'intérêt de cette nouvelle fonctionnalité 👇
Le revers de la médaille avec ces syntaxes plus complexes et logiques est qu'elles tendent à éloigner le CSS de sa nature très déclarative et à le rapprocher d'un langage de programmation avec un coût d'entrée et de maîtrise de plus en plus élevé.
Or c'est précisément cet aspect déclaratif commun à HTML et CSS qui permet de limiter la casse lorsqu'on envoie du CSS trop récent à des navigateurs trop anciens : il suffit à l'interpréteur de sauter les lignes aux propriétés ou valeurs inconnues. Du CSS pris dans des syntaxes très imbriquées devient plus beaucoup plus difficile à faire fonctionner car tout ce bloc logique sera ignoré par un moteur de rendu trop ancien.
À voir donc si cette complexification du CSS ne va pas amoindrir sa portabilité, même si des outils comme PostCSS permettent généralement de mitiger cette difficulté en transpilant le CSS moderne pour le rendre compatible avec d'anciennes versions de navigateur.