OKLCH et les couleurs CSS modernes — Pourquoi votre palette semble décalée sur certains navigateurs

Vous choisissez un bleu pour votre bouton principal. Il semble correct dans votre navigateur. Vous ouvrez le staging sur un MacBook Pro plus récent et il semble… correct — mais un peu plat. Votre concepteur envoie une capture d'écran depuis leur iPhone et le même bouton semble nettement plus vivant. Même code hexadécimal. Affichage différent.

C'est la différence entre P3. Et ce n'est en réalité que la partie la moins intéressante de la raison pour laquelle le modèle de couleur CSS que vous utilisez échoue à vous servir. Le problème majeur est la mathématique derrière l'HSL.

Le plafond de sRGB

Chaque couleur hexadécimale et rgb() valeur que vous avez jamais écrite existe dans l'espace de couleur sRGB — un standard mis en place en 1996 pour les écrans à cathode à rayons. sRGB couvre environ 35% des couleurs visibles à l'œil humain. L'espace de couleur P3, utilisé par tous les iPhones depuis 2017 et la plupart des MacBooks depuis 2016, couvre environ 45%.

Lorsque vous écrivez #3b82f6, cette couleur est limitée à sRGB. Sur un écran P3, le navigateur pourrait théoriquement afficher un bleu plus saturé — mais votre CSS ne le demande pas. Vous laissez ainsi le potentiel de l'affichage inutilisé par défaut.

Pour accéder directement aux couleurs P3, vous utiliseriez color(display-p3 0.2 0.4 0.9). Cela fonctionne. Mais ce n'est pas la raison pour laquelle OKLCH est important. Le grand échec réside dans l'hypothèse fondamentale de l'HSL.

La lumière de l'HSL est une fausse idée

L'HSL était une amélioration réelle par rapport au code hexadécimal. Hue, Saturation, Lightness — conceptuellement sensé, modifiable par les humains. Le problème : le « L » ne signifie pas ce que vous croyez.

Placez le jaune à hsl(60, 100%, 50%) et le bleu à hsl(240, 100%, 50%) côte à côte. Les deux sont exactement à 50% de luminosité.

.yellow { background: hsl(60, 100%, 50%); }
.blue   { background: hsl(240, 100%, 50%); }

Le jaune semble presque blanc. Le bleu semble demi-obscur. Ils ne sont pas proches en termes de luminosité perçue. C'est l'asymétrie perceptive de l'HSL — l'axe L ne correspond pas à la manière dont la vision humaine traite la luminosité.

Cela crée un problème réel de maintenance lors de la création d'échelles de couleurs. Si vous générez une échelle à 9 étapes en incrémentant les valeurs de L dans l'HSL, vos jaunes et vos cyanos semblent trop saturés tandis que vos bleus et vos violets semblent trop sombres. Vous êtes obligé de modifier manuellement les valeurs, ce qui annule entièrement le but d'avoir une approche systématique.

OKLCH : conçu pour la perception

OKLCH a été conçu par Björn Ottosson en 2020. Il s'appuie sur CIELAB (un espace de couleur perceptive des années 1970) mais corrige les décalages connus de tonalité — notamment le problème du violet/bleu où l'ajustement de la saturation provoque un décalage visible de la tonalité perçue.

Les trois canaux :

• L (Luminosité) — de 0 à 1, uniforme percutivement. L 0.5 en jaune semble aussi lumineux que L 0.5 en bleu. En réalité.
• C (Chroma) — commence à 0 (gris), augmente jusqu'à environ 0.3–0.4 pour des couleurs très saturées. Aucune limite fixe — la limite supérieure varie selon la tonalité et le gamut cible.
• H (Teinte) — de 0 à 360 degrés, comparable à la tonalité de l'HSL.

Voici le bleu Tailwind-500 dans les deux systèmes :

/* sRGB hex */
background: #3b82f6;

/* OKLCH equivalent — same color, different notation */
background: oklch(0.623 0.214 259.1);

/* Push chroma past sRGB — more vivid blue on P3 displays, clips gracefully on sRGB */
background: oklch(0.623 0.27 259.1);

Cette dernière valeur sort du gamut sRGB. Les navigateurs sur des écrans P3 affichent la version plus vive ; les anciens navigateurs coupent à l'équivalent sRGB le plus proche. Progression sans effort.

color-mix() et pourquoi l'espace de couleur change le mélange

color-mix() est disponible dans Chrome 111, Firefox 113 et Safari 16.2. Il mélange deux couleurs selon un rapport — assez simple. Mais l'espace de couleur que vous spécifiez change considérablement le résultat.

/* Mixes through sRGB — midpoint is a washed-out brown-grey */
background: color-mix(in srgb, oklch(0.7 0.2 30), oklch(0.7 0.2 270));

/* Mixes through the OKLCH color wheel — midpoint is a vivid purple */
background: color-mix(in oklch, oklch(0.7 0.2 30), oklch(0.7 0.2 270));

Lorsque vous mélangez orange et bleu dans sRGB, vous faites une moyenne des valeurs des canaux. Le point milieu passe par un gris brun décoloré. Dans OKLCH, vous interpolez le long de la roue des couleurs — vous arrivez sur un violet vibrant. Ce qui est correct dépend de l'intention, mais pour les transitions UI, les gradients et les états hover, l'interpolation OKLCH est presque toujours ce que vous voulez.

Utilisation pratique : générer un état désactivé sans coder une deuxième valeur hexadécimale.

.button--disabled {
  background: color-mix(in oklch, var(--color-primary) 40%, white);
  cursor: not-allowed;
}

Syntaxe de couleur relative

La syntaxe de couleur relative (Chrome 119+, Firefox 128+, Safari 16.4+) vous permet de dériver une nouvelle couleur en modifiant les canaux d'une couleur existante :

:root {
  --brand: oklch(0.623 0.214 259.1);
}

.button:hover {
  /* Lighten by 8% lightness units */
  background: oklch(from var(--brand) calc(l + 0.08) c h);
}

.button:active {
  /* Darken and reduce chroma slightly */
  background: oklch(from var(--brand) calc(l - 0.08) calc(c - 0.02) h);
}

.button--muted {
  /* Drop chroma to near-zero: perceptual grey at the same lightness */
  background: oklch(from var(--brand) l 0.03 h);
}

Cela remplace les fonctions de Sass’s lighten(), darken()et desaturate() par du CSS natif — sans préprocesseur, sans étape de construction, sans valeurs hexadécimales parallèles à synchroniser. Et puisque vous êtes dans OKLCH, « éclaircir » semble vraiment plus clair pour chaque tonalité de votre palette, et non seulement pour certaines d'entre elles.

Une limitation réelle : les contraintes complexes sur les canaux (comme la limitation de la saturation pour rester dans le gamut) nécessitent des chaînes de syntaxe longues qui deviennent rapidement complexes. Pour des modifications simples de luminosité et de saturation, la syntaxe est propre. Pour des cas plus sophistiqués, le calcul des valeurs à la construction et la génération de propriétés CSS est plus maintenable. calc() Support des navigateurs en 2026

Chrome

est supérieur à 90% à mi-2026. Les exceptions sont les navigateurs d'entreprise basés sur Chromium plus anciens et tout ce qui tourne encore sur Firefox avant 113. Si ces navigateurs font partie de votre base d'utilisateurs, un retour à deux lignes suffit : oklch() En pratique : si vos données d'analyse confirment Chrome 111+, Firefox 113+ et Safari 15.4+, vous pouvez ignorer complètement le retour. Le

.button {
  background: #3b82f6; /* sRGB fallback */
}

@supports (background: oklch(0 0 0)) {
  .button {
    background: oklch(0.623 0.214 259.1);
  }
}

wrapper est destiné à apporter une sécurité dans les outils internes où vous ne contrôlez pas les versions de navigateurs. @supports Conversion de votre palette existante

Le point de friction avec l'adoption de l'OKLCH est de passer de vos valeurs hexadécimales actuelles aux coordonnées OKLCH et de comprendre ce que signifient les canaux pour chaque couleur. Le

gère la conversion dans les deux sens — collez une valeur hexadécimale ou HSL, obtenez des valeurs OKLCH, puis commencez à ajuster L et C à partir d'un point de référence réel. Il supporte HSL, RGB, Lab, LCH, HSV et OKLCH dans un même endroit, ce qui est utile lorsque vous travaillez à partir d'un fichier Figma qui vous donne des valeurs hexadécimales et que vous devez atteindre des valeurs OKLCH que vous pouvez raisonner. Convertisseur d'espace de couleur unifié Comment migrer réellement

Vous n'avez pas besoin de réécrire tout de suite. Une séquence pratique :

Commencez par les couleurs interactives

1. — vos tokens principaux, secondaires et destructifs. Ces sont les couleurs que vous générez déjà en version hover, active et désactivée. L'OKLCH avec la syntaxe de couleur relative remplace immédiatement cette logique en CSS natif. Laissez les couleurs statiques en hexadécimal pour l'instant
2. — texte, fonds, bordures. Elles ne sont pas manipulées de manière programmée, donc il n'y a pas de gain à les convertir pour l'instant. Construisez le nouveau système de base à partir de zéro en OKLCH
3. — c'est là que les gains de perception deviennent structurels. Votre échelle neutre au niveau 500 sera effectivement au milieu visuel, et vos teintes saturées seront cohérentes pour toutes les tonalités sans ajustement manuel. L'objectif n'est pas d'utiliser OKLCH pour son propre compte. C'est d'avoir un système de couleurs où les calculs correspondent à ce que voient vos yeux — afin que vous cessiez de compenser manuellement chaque fois que vous avez besoin d'un bleu légèrement plus clair.

OKLCH et les couleurs CSS modernes — Pourquoi votre palette semble-t-elle différente dans certains navigateurs 2

Vous aimerez peut-être aussi

Nouveau

Pagination basée sur le curseur versus pagination par décalage — Pourquoi page=2 supprime silencieusement des enregistrements

En savoir plus "

Mis à jour le 15 juin 2026

Nouveau

Builds multistage Docker : Réduisez votre image sans compromettre le déploiement

En savoir plus "

Mis à jour le 14 juin 2026

Nouveau

Flux OAuth 2.0 : Code d'autorisation, PKCE et identifiants du client

En savoir plus "

Mis à jour le 13 juin 2026

Nouveau

HTTP/2 vs HTTP/3 : Qu'est-ce qui a réellement changé (et si votre API s'y intéresse)

En savoir plus "

Mis à jour le 12 juin 2026