OKLCH dans Tailwind v4

Tailwind v4 a reconstruit sa palette de couleurs par défaut en OKLCH et déplacé la configuration dans le CSS lui-même : les couleurs personnalisées sont désormais de simples propriétés personnalisées CSS écrites en oklch(), déclarées sous la directive @theme plutôt que dans tailwind.config.js. La palette reconstruite progresse plus régulièrement et atteint le surcroît d’éclat des écrans P3 à large gamut — et ces deux propriétés sont accessibles à vos propres couleurs de marque, si vous construisez la rampe comme les valeurs par défaut ont été construites.

C’est ce dernier point qui nous intéresse vraiment ici : non pas utiliser les couleurs de Tailwind, mais faire en sorte qu’une palette personnalisée se comporte comme elles. Le modèle de couleur qui fait le travail a sa propre série dans notre guide OKLCH.

Qu’est-ce qui a changé côté couleur dans Tailwind v4 ?

Deux évolutions sont arrivées ensemble.

La palette par défaut a été régénérée en OKLCH. Ouvrez la référence des couleurs dans la doc Tailwind et les valeurs sont des chaînes oklch() plutôt que des hex. Les effets concrets : au sein de chaque échelle, les paliers sont perceptuellement plus réguliers, et sur les écrans Display-P3 les tons moyens portent un chroma que le hex sRGB ne pouvait pas exprimer — la palette paraît plus éclatante sur la plupart des téléphones et ordinateurs portables actuels, sans aucun changement de nom de classe.

La configuration passe d’abord par le CSS. La directive @theme remplace une grande partie de tailwind.config.js : les design tokens sont des propriétés personnalisées CSS déclarées dans votre feuille de style, et Tailwind en génère les utilitaires. Les couleurs vivent sous l’espace de noms --color-*. Une conséquence qui mérite d’être notée avant même d’aborder la théorie des couleurs : votre palette réside désormais dans le même fichier et le même langage que le reste de votre CSS, lisible et modifiable sur place.

Comment définir des couleurs de marque personnalisées dans @theme ?

Déclarez des propriétés nommées --color-<name>-<step>, et les utilitaires suivent :

@import "tailwindcss";

@theme {
  --color-brand-100: oklch(0.93 0.03 262.9);
  --color-brand-300: oklch(0.78 0.10 262.9);
  --color-brand-500: oklch(0.60 0.19 262.9);
  --color-brand-600: oklch(0.546 0.215 262.9); /* #2563eb */
  --color-brand-700: oklch(0.49 0.19 262.9);
  --color-brand-900: oklch(0.36 0.12 262.9);
}

Avec ce bloc en place, bg-brand-600, text-brand-100, border-brand-300 et tous les autres utilitaires de couleur fonctionnent exactement comme pour la palette intégrée.

Ces valeurs sont un exemple travaillé, pas du remplissage. Le palier 600 est la couleur de départ : oklch(0.546 0.215 262.9) correspond exactement à #2563eb, le bleu que Tailwind v3 livrait sous le nom blue-600. Les cinq autres en ont été générées — la teinte maintenue à 262,9 sur toute la rampe, la luminosité suivant une courbe, le chroma épousant un profil en cloche qui culmine près de la couleur de départ et s’atténue vers les deux extrémités. Leurs jumeaux hex tombent à ≈ #dde8fd, #95b7f8, #3f78f0, #2055ca et #19387b.

Qu’est-ce qu’OKLCH vous apporte par rapport au collage de codes hex ?

La rampe se comporte comme celle de Tailwind. Les échelles par défaut paraissent régulières parce qu’elles ont été générées sur un modèle perceptuel ; une échelle de marque assemblée à la main en hex ne l’était généralement pas, si bien qu’elle cohabite dans le même projet avec une physique différente — l’écart de brand-500 à brand-600 n’a pas la même taille que le même écart dans gray, les dérivations de survol tombent de façon inégale, et le contraste doit être testé paire par paire au lieu de se lire dans la colonne de luminosité. Une rampe de marque générée en OKLCH hérite des propriétés pour lesquelles la palette par défaut a été reconstruite : des paliers réguliers et un contraste que vous pouvez prédire à partir des valeurs de L.

Les valeurs répondent aussi. #2563eb et #2055ca ne vous disent rien de leur rapport ; oklch(0.546 0.215 262.9) et oklch(0.49 0.19 262.9) vous le disent précisément — même teinte, un palier plus sombre, un peu moins coloré. C’est la raison intuitive pour laquelle OKLCH a sa place dans un fichier de thème : les nombres correspondent enfin à la façon dont les designers se décrivent déjà la couleur entre eux — « pareil, mais plus sombre » — si bien que l’édition sur place devient raisonnable. Si brand-600 paraît trop lourd, augmentez son L de 0,02 et vous savez précisément ce que vous avez changé.

Ouvrez cette rampe de marque avec son export Tailwind dans Scale Composer — l’échelle ci-dessus, générée à partir de la couleur de départ #2563eb, avec le bloc @theme assemblé dans le panneau d’export et le hex à côté de chaque palier.

À quoi ressemble le flux de travail générer-puis-coller ?

Trois gestes, aucun d’eux n’étant du réglage à la main :

1. Départ. Collez la couleur de marque — le hex convient ; elle est convertie en coordonnées OKLCH et la rampe est générée autour d’elle : des paliers sur une courbe de luminosité, un profil de chroma en cloche avec un plancher pour que les paliers les plus pâles gardent une trace de la teinte, et un chroma plafonné juste en dessous du plafond du gamut pour qu’aucun palier ne soit écrêté. Une variante mode sombre peut être dérivée de la même rampe, avec sa propre courbe de luminosité et un renfort de chroma.
2. Vérification. Les planchers de contraste sont évalués par rôle (WCAG, avec APCA en complément), de sorte que les paliers que vous destinez au texte et aux arrière-plans sont vérifiés avant tout export.
3. Export. L’export Tailwind v4 tient dans un seul bloc @theme — les échelles de couleur plus, si vous les voulez, les niveaux typographiques, l’espacement, les rayons et les points de rupture dans le même dialecte. Collez-le dans votre feuille de style et les utilitaires existent.

OKLCH change-t-il le fonctionnement des utilitaires ?

Non — et il vaut la peine de le dire clairement. bg-brand-600 se comporte de façon identique que la propriété sous-jacente contienne une valeur oklch() ou un code hex ; les noms de classe, les variantes et le pipeline de build sont indifférents à la notation. OKLCH change la qualité des valeurs — des paliers réguliers, l’édition sur place, la portée P3 — pas l’API. Cela veut aussi dire que la migration peut être incrémentale : les nouveaux tokens peuvent être écrits en oklch() tandis que les tokens hex existants restent intacts jusqu’à ce que vous ayez une raison de les régénérer. Le oklch() natif est disponible dans tous les grands navigateurs depuis 2023, donc pour les cibles actuelles aucune transformation de build n’intervient.

Quel est le moyen le plus rapide de l’essayer avec votre propre marque ?

La rampe d’exemple ci-dessus est le résultat d’une seule couleur de départ ; le flux de travail est le même pour n’importe quelle couleur. Déposez votre propre couleur de marque comme couleur de départ — elle est convertie en OKLCH, la rampe est générée selon les mêmes règles que l’exemple, et le bloc @theme du panneau d’export est prêt à coller.