Je partage une petite mésaventure qui m'est arrivée en CSS, il est fort probable que je ne sois pas le seul qui puisse commettre de bonne foi cette erreur.

L'autre jour, je me retrouve à utiliser max en CSS pour effectuer une adaptation de Proton Calendar pour des écrans gigantesques (ou si on dézoome fortement).

Grosso modo, le code en question est (le détail de la valeur n'est même pas important) :

block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24))

En clair, prends-moi la valeur maximum entre les deux valeurs, ce qui m'assure que si l'écran n'est pas gigantesque, l'élément en question fera au moins 3rem quoi qu'il arrive. Rien de bien extraordinaire, je me dis que c'est même assez bulletproof — en anglais dans le texte, construit ainsi en amélioration progressive. Personne ne trouve à redire.

Quelques jours plus tard, je reçois des retours, quelques utilisateurs ont des soucis. J'investigue un peu, et je me rends compte que ce sont de vieux navigateurs qui pêchent (des Firefox/Chrome 87 ou des Safari 15.x). Là, j'avoue que je suis surpris : cette syntaxe me parait pourtant à l'épreuve des balles. Quand bien même les navigateurs ne supporteraient pas l'unité lvh, max entre 3rem et un truc pas supporté, c'est 3rem qui gagne, logiquement.

Je fouille un peu dans la spécification, ouvre une question sur le CSS Working group, et là… surprise motherf***** !

En fait, si une des valeurs renvoie failure, l'intégralité de l'expression renvoie failure. En clair pour mon cas, si les lvh ne sont pas supportés, kaboom, la comparaison avec max foire totalement !

J'avoue avoir été surpris ! Ceci dit, le fix a été simplement d'entourer la version avec un @supports avec ce qu'il faut dedans :

block-size: 3rem;
@supports ( block-size: ( max(1rem, 100lvh) ) ) {
  block-size: max(3rem, calc((100lvh - 3.75rem - 4.75rem) / 24))
}

Comme quoi, on a toujours des surprises…