Deterministic colour

This site has no colour picker anywhere in its history. Every surface you see is computed: six hues chosen in OKLCH, one lightness, one chroma, and a hash function. This post is about why that constraint exists and what it bought.

The problem with picking colours by eye is not taste; it's fairness. This site is six sections that must feel like siblings — same lightness, same saturation, different hue — and human eyes are famously bad judges of that. A yellow and a blue with the same HSL "lightness" are nowhere near equally light. OKLCH fixes the yardstick: oklch(0.88 0.055 h) is perceptually the same pastel whatever you substitute for h, which is the whole mirror idea in one line of CSS.

Posts go one step further. Each post's surface drifts from its section's base by a few degrees of hue and a few hundredths of lightness — enough to feel, too little to name — and the drift is a pure function of the slug:

export function shadeFor(section: SectionKey, slug = '') {
  const base = SECTIONS[section].hue;
  const h = hash(slug); // FNV-1a — stable forever, everywhere
  return {
    hue: base + ((h & 0xff) / 255 - 0.5) * 16, // ±8°
    L: BASE.L + (((h >> 8) & 0xff) / 255 - 0.5) * 0.06, // ±0.03
    C: BASE.C + (((h >> 16) & 0xff) / 255 - 0.5) * 0.03, // ±0.015
  };
}

Try it — this widget runs the real function, live:

Deterministic means accountable. The same post is the same colour forever, on every build, on every machine. No database row stores it; no human maintains it. And because the palette is a function, it can be tested like one — the build runs every derivable shade against WCAG contrast thresholds and refuses to ship if a single combination fails. Taste gets you a nice palette; a build gate keeps it nice.

The full derivation lives in the colophon, because on a site about a mirror, showing your work is the brand.