What are OKLCH colors?

Original Article ↗ Hacker News Discussion ↗

Relationship between OKLCH and OKLab / other spaces

  • OKLCH is OKLab in polar coordinates (L = lightness, C = chroma, H = hue); mathematically the same space but a different coordinate system.
  • Several comments compare it with CIELAB/CIELCh: OKLCH is described as a “bugfix” for CIELAB, with better perceptual behavior (e.g., desaturating pure blue no longer passes through visibly purple).
  • Some people prefer HSLuv or hope for OKHSL/OKHSV as more intuitive, hue-stable frontends that hide gamut boundaries.

Gradients and gamut problems

  • A major thread critiques the article’s “better gradients” claim.
  • In OKLCH, hue is an angle, so interpolating hue can take a long path around the circle, passing through unexpected colors (e.g., magenta→lime going via red–yellow or via blue–aqua).
  • Much of that circular path lies outside sRGB, P3, even Rec.2020 and sometimes beyond human vision. Gamut‑mapping algorithms pull colors back in, breaking perceptual uniformity (e.g., darkened reds, banding).
  • Some argue OKLab is better for gradients: it interpolates as a straight line, often passing through gray but avoiding wild hue detours and extreme out‑of‑gamut segments. Tailwind reportedly tried OKLCH for gradients then switched to OKLab as a safer default.
  • Others note there is no single “correct” gradient; going through gray can be undesirable depending on the use case, and hand‑placed stops are often best.

Perceptual uniformity vs hue drift

  • Supporters like that OKLCH lets you change lightness while mostly preserving perceived “colorfulness,” making palette building and relative CSS colors easier.
  • Critics call out examples where increasing lightness shifts blue visibly towards cyan, contradicting the article’s claim of “no hue drift.” This is attributed to hitting gamut boundaries: OKLCH tends to preserve chroma and sacrifice hue when clipping.
  • Debate ensues over whether sacrificing hue is acceptable; some see it as a fundamental flaw, others as a design choice in an inherently compromised problem.

Hardware limits and gamuts

  • Wider‑gamut monitors (P3, Rec.2020) reduce but don’t eliminate issues; many problematic gradients request colors “way” outside any practical gamut.
  • There’s discussion on why gamut edges are non‑linear, why some colors (e.g., very bright pure red) don’t exist, and why mapping out‑of‑gamut colors is intrinsically messy.

Accessibility and contrast

  • Commenters remind that choosing colors also needs contrast checking (APCA vs WCAG 2).
  • APCA is seen as perceptually better, especially for dark themes, but WCAG 2 remains a legal requirement in many contexts; tools exist to test both.
  • There is a side debate about contrast formula design (ratio vs difference, edge cases, approximations).

Practical usage and tooling

  • Several people report good experiences using OKLCH plus relative CSS colors to derive entire themes from a few base colors.
  • Pain points: learning non‑HSL hue numbers, difficulty adding “warmth,” handling out‑of‑gamut issues, and lack of polished gradient pickers that expose clipping options.
  • Consensus: OKLCH is a powerful, more perceptual base, but designers still need taste, hand‑tuning, and awareness of its failure modes.