# OKLCH

# HSL-L ist nicht „wahrgenommene Helligkeit“ 🎨

Der `L`-Wert in **HSL** ist nur eine geometrische Größe innerhalb dieses Farbmodells, aber **nicht** so definiert, dass Menschen Farben bei gleichem `L` als gleich hell wahrnehmen.

Ein typisches Beispiel:

- ein kräftiges **Gelb**
- ein kräftiges **Blau**

können in HSL denselben `L`-Wert haben, aber Gelb wirkt trotzdem viel heller als Blau.

---

## Warum ist das so?

HSL basiert letztlich auf dem üblichen **RGB-Farbraum**. Dieser ist praktisch für Bildschirme, aber nicht *wahrnehmungslinear*.

Das heißt:

- gleiche numerische Änderungen in RGB oder HSL
- führen **nicht** zu gleich großen visuellen Änderungen

Insbesondere ist unser Auge für verschiedene Farbbereiche unterschiedlich empfindlich:

- **Gelb/Grün** wirkt oft sehr hell
- **Blau** wirkt oft deutlich dunkler
- obwohl die technischen Werte „ähnlich“ aussehen

---

## Was man stattdessen braucht

Wenn du Farben *wirklich gleich hell* machen willst, brauchst du einen **perzeptuell gleichmäßigeren Farbraum**. Dafür gibt es mathematische Modelle.

Die wichtigsten sind:

1. **CIELAB / L\*a\*b\***
   - `L*` steht näher an der wahrgenommenen Helligkeit
   - deutlich besser als HSL

2. **CIELUV**
   - ähnlicher Zweck, etwas anderer Schwerpunkt

3. **OKLab / OKLCH**
   - moderner
   - für UI, Web und Design oft sehr gut geeignet
   - in vielen Fällen heute die praktisch beste Wahl

---

## Die eigentliche Idee: „Luminanz“ und „perzeptuelle Helligkeit“

Es gibt dabei zwei verwandte, aber verschiedene Dinge:

### 1. Physikalische bzw. technische Helligkeit: relative Luminanz

Für einen sRGB-Farbwert berechnet man zunächst die **relative Luminanz** $Y$.

Wenn `R`, `G`, `B` im Bereich 0 bis 1 als **lineare** RGB-Werte vorliegen, dann gilt:

$$
Y = 0.2126 R + 0.7152 G + 0.0722 B
$$

Wichtig: Das sind **lineare** RGB-Werte, nicht die direkt aus CSS bekannten 8-Bit-sRGB-Werte.

Vorher muss man sRGB erst linearisieren. Für einen sRGB-Kanal $c_{srgb}$ gilt:

$$
c_{lin} =
\begin{cases}
\frac{c_{srgb}}{12.92}, & c_{srgb} \le 0.04045 \\
\left(\frac{c_{srgb}+0.055}{1.055}\right)^{2.4}, & c_{srgb} > 0.04045
\end{cases}
$$

Diese Luminanz ist z. B. wichtig für:

- **Kontrastberechnungen**
- WCAG
- technische Lichtstärke-Vergleiche

Aber: gleiche Luminanz ist noch nicht perfekt dasselbe wie „gleich hell empfunden“.

---

### 2. Wahrgenommene Helligkeit: perzeptuelle Lightness

Dafür gibt es z. B. in **CIELAB** die Größe $L^*$.

Aus der relativen Luminanz $Y$ und dem Referenz-Weiß $Y_n$ wird näherungsweise berechnet:

$$
L^* = 116 \cdot \left(\frac{Y}{Y_n}\right)^{1/3} - 16
$$

für größere Werte; genauer ist die Definition stückweise, aber die Grundidee ist:

- nicht linear,
- sondern an die menschliche Wahrnehmung angepasst.

**Gleiche $L^*$-Werte** sind viel näher an „gleich hell“ als gleiche HSL-`L`-Werte.

---

## Für CSS heute besonders interessant: OKLCH

Für praktische Arbeit im Web ist **OKLCH** oft die beste Antwort.

OKLCH besteht aus:

- **L** = wahrgenommene Helligkeit
- **C** = Chroma / Farbstärke
- **H** = Farbwinkel

Das ist also ähnlich intuitiv wie HSL, aber viel besser an die Wahrnehmung angepasst.

### Vorteil

Wenn du in OKLCH den **gleichen `L`-Wert** verwendest, wirken Farben wesentlich eher gleich hell.

Beispiel in CSS:

```css
color: oklch(0.7 0.15 30);
color: oklch(0.7 0.15 120);
color: oklch(0.7 0.15 260);
```

Hier ist die Helligkeit durch `0.7` deutlich konsistenter als bei vergleichbaren HSL-Farben.

---

## Also: Gibt es eine mathematische Rechenweise?

**Ja.** Sogar mehrere — je nachdem, was du mit „hell“ meinst:

1. **Gleiche technische Luminanz**
   - über lineares RGB und
     $$
     Y = 0.2126 R + 0.7152 G + 0.0722 B
     $$
   - gut für Kontrast und Messbarkeit

2. **Gleiche wahrgenommene Helligkeit**
   - über **CIELAB `L*`** oder besser **OKLab/OKLCH `L`**
   - gut für Design, UI und Farbpaletten

---

## Praktische Empfehlung

Wenn dein Ziel ist:

### „Farben sollen im Interface gleich hell wirken“
Dann nimm **OKLCH** statt HSL.

### „Ich will Kontraste mathematisch korrekt prüfen“
Dann arbeite mit **relativer Luminanz**.

### „Ich will ein älteres, etabliertes Farbmodell“
Dann ist **CIELAB** eine gute Wahl.

---

## Warum HSL trotzdem oft benutzt wird

HSL ist beliebt, weil es sehr intuitiv aussieht:

- `H` = Farbton
- `S` = Sättigung
- `L` = hell/dunkel

Aber dieses `L` ist eher ein *Modellparameter* als echte visuelle Helligkeit.

Man kann HSL gut verwenden für:

- einfache Farbvarianten
- schnelle Prototypen
- kleine Anpassungen

Aber nicht, wenn du exakt gleich helle Farben willst.

---

## Kurzfassung

**Ja**, dafür gibt es mathematische Modelle.  
Wenn Farben **wirklich gleich hell wirken** sollen, ist **HSL ungeeignet**.

Am besten nimmst du:

- **OKLCH** für praktische CSS-/UI-Arbeit
- oder **CIELAB / OKLab**, wenn du mathematisch sauber in perzeptuellen Farbräumen arbeiten willst

Wenn du möchtest, kann ich dir als Nächstes noch zeigen:

1. **warum HSL-L mathematisch so definiert ist**,  
2. **wie man eine HSL-Farbe in relative Luminanz umrechnet**, oder  
3. **wie man in CSS mit OKLCH eine gleichhelle Farbpalette baut**.

# OKLCH - SCSS/SASS - Dark/Light Mode

Wenn deine Farben bereits als `oklch(...)` vorliegen, kannst du eine Funktion bauen, die einfach den **Lightness-Wert umkehrt**:

$$
L_{\text{neu}} = 1 - L
$$

Also aus:

```scss
oklch(0.3 0.15 30)
```

wird:

```scss
oklch(0.7 0.15 30)
```

---

## Einfache Sass-Funktion

```scss
@use "sass:color";
@use "sass:math";

@function invert-oklch-lightness($c) {
  $space: color.space($c);

  @if $space != oklch {
    @error "invert-oklch-lightness erwartet eine OKLCH-Farbe, bekommen: #{$space}";
  }

  $l: color.channel($c, "lightness", $space: oklch);
  $chroma: color.channel($c, "chroma", $space: oklch);
  $hue: color.channel($c, "hue", $space: oklch);

  $new-l: 1 - $l;

  @return oklch($new-l $chroma $hue);
}
```

### Verwendung

```scss
$color: oklch(0.3 0.15 30);
$dark-mode: invert-oklch-lightness($color);
```

Ergebnis:

```scss
oklch(0.7 0.15 30)
```

---

## Beispiel im Einsatz

```scss
@use "sass:color";

@function invert-oklch-lightness($c) {
  @if color.space($c) != oklch {
    @error "Nur OKLCH-Farben sind erlaubt.";
  }

  $l: color.channel($c, "lightness", $space: oklch);
  $chroma: color.channel($c, "chroma", $space: oklch);
  $hue: color.channel($c, "hue", $space: oklch);

  @return oklch(1 - $l $chroma $hue);
}

$bg-light: oklch(0.92 0.03 240);
$bg-dark: invert-oklch-lightness($bg-light);

$accent-light: oklch(0.3 0.15 30);
$accent-dark: invert-oklch-lightness($accent-light);

:root {
  --bg: #{$bg-light};
  --accent: #{$accent-light};
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #{$bg-dark};
    --accent: #{$accent-dark};
  }
}
```

---

## Wichtiger Hinweis

Das ist **mathematisch simpel**, aber **gestalterisch nicht immer optimal** ✨

Denn ein „guter“ Dark-Mode ist oft **nicht nur**:

1. Lightness invertieren
2. Chroma gleich lassen
3. Hue gleich lassen

Sondern häufig will man zusätzlich:

- **Chroma etwas reduzieren**, weil kräftige Farben auf dunklem Hintergrund schnell zu intensiv wirken
- bei sehr hellen Farben ein anderes Mapping verwenden
- Kontraste für Text gezielt anpassen

---

## Etwas robustere Variante

Wenn du willst, kannst du beim Invertieren gleichzeitig die Chroma leicht dämpfen:

```scss
@use "sass:color";
@use "sass:math";

@function dark-mode-oklch($c, $chroma-factor: 0.85) {
  @if color.space($c) != oklch {
    @error "Nur OKLCH-Farben sind erlaubt.";
  }

  $l: color.channel($c, "lightness", $space: oklch);
  $chroma: color.channel($c, "chroma", $space: oklch);
  $hue: color.channel($c, "hue", $space: oklch);

  $new-l: 1 - $l;
  $new-chroma: $chroma * $chroma-factor;

  @return oklch($new-l $new-chroma $hue);
}
```

Beispiel:

```scss
$color: oklch(0.3 0.15 30);
$dark: dark-mode-oklch($color);
```

Ergibt ungefähr:

```scss
oklch(0.7 0.1275 30)
```

---

## Falls du nur rohe Werte übergeben willst

Wenn du lieber direkt mit Zahlen statt mit einem Farbwert arbeitest:

```scss
@function invert-oklch($l, $c, $h) {
  @return oklch(1 - $l $c $h);
}
```

Verwendung:

```scss
$color: invert-oklch(0.3, 0.15, 30);
```

---

## Fazit

**Ja, absolut.**  
Für deinen konkreten Fall reicht im Prinzip genau das:

```scss
@function invert-oklch-lightness($c) {
  $l: color.channel($c, "lightness", $space: oklch);
  $chroma: color.channel($c, "chroma", $space: oklch);
  $hue: color.channel($c, "hue", $space: oklch);

  @return oklch(1 - $l $chroma $hue);
}
```

Wenn du möchtest, kann ich dir als Nächstes auch noch eine Version schreiben, die:

1. **auch normale CSS-Strings wie `oklch(0.3 0.15 30)` verarbeitet**, oder
2. **eine ganze Sass-Map mit Theme-Farben automatisch in Dark-Mode-Werte umwandelt**.

# HSL lightness is not true perceived brightness 🎨

The `L` value in **HSL** is only a geometric quantity within that color model. It is **not** defined so that colors with the same `L` are perceived by humans as equally bright.

A typical example:

1. a strong **yellow**
2. a strong **blue**

can have the same HSL `L` value, yet yellow will still appear much brighter than blue.

## Why is that?

HSL is ultimately based on the usual **RGB color space**. RGB is practical for displays, but it is not *perceptually uniform*.

That means:

1. equal numerical changes in RGB or HSL
2. do **not** produce equally large visual changes

In particular, our eyes are not equally sensitive across all hues:

1. **yellow/green** often appears very bright
2. **blue** often appears much darker
3. even when the technical values look similar

## What you need instead

If you want colors to be *truly equally bright*, you need a **more perceptually uniform color space**. There are mathematical models for that.

The most important ones are:

1. **CIELAB / L\*a\*b\***
   1. `L*` is much closer to perceived lightness
   2. much better than HSL

2. **CIELUV**
   1. similar purpose
   2. slightly different focus

3. **OKLab / OKLCH**
   1. more modern
   2. often very well suited for UI, web, and design work
   3. in many cases, the best practical choice today

## The core idea: “luminance” vs. “perceived lightness”

These are related, but not the same thing.

### 1. Physical or technical brightness: relative luminance

For an sRGB color, you can first compute the **relative luminance** $Y$.

If `R`, `G`, and `B` are **linear** RGB values in the range from 0 to 1, then:

$$
Y = 0.2126 R + 0.7152 G + 0.0722 B
$$

Important: these are **linear** RGB values, not the raw 8-bit sRGB values you typically use in CSS.

So first, sRGB must be linearized. For an sRGB channel $c_{srgb}$:

$$
c_{lin} =
\begin{cases}
\frac{c_{srgb}}{12.92}, & c_{srgb} \le 0.04045 \\
\left(\frac{c_{srgb}+0.055}{1.055}\right)^{2.4}, & c_{srgb} > 0.04045
\end{cases}
$$

This luminance is important for things like:

1. **contrast calculations**
2. WCAG
3. technical comparisons of brightness

But equal luminance is still not perfectly the same as “equally bright as perceived.”

### 2. Perceived brightness: perceptual lightness

For this, **CIELAB** uses the quantity $L^*$.

From the relative luminance $Y$ and the reference white $Y_n$, it is approximately calculated as:

$$
L^* = 116 \cdot \left(\frac{Y}{Y_n}\right)^{1/3} - 16
$$

for larger values; more precisely, the full definition is piecewise. But the main idea is:

1. it is not linear
2. it is adjusted to human perception

**Equal $L^*$ values** are much closer to “equally bright” than equal HSL `L` values.

## Especially relevant for CSS today: OKLCH

For practical work on the web, **OKLCH** is often the best answer.

OKLCH consists of:

1. **L** = perceived lightness
2. **C** = chroma / colorfulness
3. **H** = hue angle

So it is similar to HSL in terms of intuition, but much better aligned with perception.

### Advantage

If you use the same `L` value in OKLCH, colors are much more likely to appear equally bright.

Example in CSS:

```css
color: oklch(0.7 0.15 30);
color: oklch(0.7 0.15 120);
color: oklch(0.7 0.15 260);
```

Here, the lightness set by `0.7` is much more consistent than in comparable HSL colors.

## So: is there a mathematical way to do this?

**Yes.** In fact, there are several—depending on what exactly you mean by “equally bright”:

1. **Equal technical luminance**
   1. using linear RGB and
      $$
      Y = 0.2126 R + 0.7152 G + 0.0722 B
      $$
   2. good for contrast and measurable brightness

2. **Equal perceived lightness**
   1. using **CIELAB `L*`** or, better, **OKLab/OKLCH `L`**
   2. good for design, UI, and color palettes

## Practical recommendation

If your goal is:

### “Colors should appear equally bright in an interface”

Use **OKLCH** instead of HSL.

### “I want mathematically correct contrast checks”

Work with **relative luminance**.

### “I want an older, well-established color model”

Then **CIELAB** is a good choice.

## Why HSL is still often used

HSL is popular because it feels intuitive:

1. `H` = hue
2. `S` = saturation
3. `L` = light/dark

But that `L` is more of a *model parameter* than a true measure of visual lightness.

HSL can still be useful for:

1. simple color variations
2. quick prototypes
3. small adjustments

But not if you want colors that are precisely equal in perceived brightness.

## Short version

**Yes**, there are mathematical models for this.  
If colors should **really appear equally bright**, **HSL is not suitable**.

The best options are:

1. **OKLCH** for practical CSS and UI work
2. **CIELAB / OKLab** if you want to work in perceptually meaningful color spaces more rigorously

If you want, I can also show you next:

1. **why HSL lightness is defined the way it is**
2. **how to convert an HSL color into relative luminance**
3. **how to build an equal-lightness color palette in CSS using OKLCH**

# Ways to define colors in CSS — from HEX to OKLCH 🎨

CSS has accumulated quite a few ways to describe color over the years. Some are familiar and compact, like `#ff0000`; some are practical and expressive, like `rgb(255 0 0 / 0.5)`; and some are modern, powerful, and much better aligned with human perception—especially **`oklch()`**.

If you write CSS today, it’s worth understanding not just *how* these formats work, but *when* each one makes sense. This article walks through the main color syntaxes in CSS, explains their strengths and trade-offs, and gives special attention to **OKLCH**, which is becoming one of the most useful ways to work with color in modern design systems.

## Why CSS has so many color formats

Different color formats exist because they solve different problems:

1. **Convenience**
   1. Named colors like `red` are easy to remember.
   2. HEX is compact and common in design tools.

2. **Control**
   1. `rgb()` and `hsl()` make it easier to think in channels.
   2. Alpha transparency can be expressed clearly.

3. **Color science**
   1. Newer spaces like `lab()`, `lch()`, `oklab()`, and `oklch()` aim to make color adjustments more perceptually meaningful.
   2. They help produce more consistent palettes, gradients, and theme systems.

In short: older formats are still useful, but newer ones are often better for design work that needs consistency and nuance.

## Named colors

CSS supports a long list of predefined color keywords:

```css
color: red;
background: rebeccapurple;
border-color: lightgray;
```

These are readable and quick, but they have limits:

1. They cover only a fixed set of colors.
2. They aren’t precise enough for most branding or system design.
3. Their perceived brightness and saturation vary widely.

Named colors are nice for demos, quick experiments, and a few memorable values like `white`, `black`, `transparent`, or `rebeccapurple`. For serious visual design, developers usually move to numeric color functions.

## HEX colors

HEX is one of the most recognizable CSS color formats:

```css
color: #ff0000;
color: #f00;
```

These two values mean the same thing: pure red.

### How HEX works

A 6-digit HEX color is structured like this:

```css
#RRGGBB
```

Each pair is a channel from `00` to `ff`:

1. `RR` = red
2. `GG` = green
3. `BB` = blue

So:

```css
#ff0000 /* red */
#00ff00 /* green */
#0000ff /* blue */
#ffffff /* white */
#000000 /* black */
```

There is also shorthand:

```css
#f00   /* equivalent to #ff0000 */
#0f0   /* equivalent to #00ff00 */
#fff   /* equivalent to #ffffff */
```

And alpha can be included too:

```css
#ff000080 /* red at about 50% opacity */
#f008     /* shorthand with alpha */
```

### When HEX is useful

HEX is popular because it is:

1. **Compact**
2. **Widely recognized**
3. **Easy to copy from design tools**

But it also has some drawbacks:

1. It’s not very intuitive for humans.
   1. Looking at `#7a5ccf` doesn’t tell you much immediately.

2. Adjusting colors manually is awkward.
   1. Making something “a bit lighter” is not straightforward.

3. It reflects RGB encoding rather than human perception.
   1. Equal numeric changes do not feel like equal visual changes.

HEX is still common and totally valid, but it’s often best thought of as a storage or interchange format rather than the most ergonomic design format.

## RGB and RGBA

RGB expresses colors through red, green, and blue channels:

```css
color: rgb(255 0 0);
color: rgb(255, 0, 0);
```

Both forms are understood in CSS, though the space-separated modern syntax is generally preferred.

You can also include alpha:

```css
color: rgb(255 0 0 / 50%);
color: rgb(255 0 0 / 0.5);
```

### Why RGB is useful

RGB maps directly to how screens emit light, so it is fundamental in digital color. It’s often useful when:

1. You need direct channel control.
2. You want explicit alpha handling.
3. You are working with JavaScript, canvas, or generated colors.

Example:

```css
background-color: rgb(34 197 94 / 0.2);
```

That said, RGB has the same conceptual limitation as HEX: it is not a perceptual color space. Two colors with similar channel differences may not *look* similarly different.

## HSL and HSLA

HSL stands for **Hue, Saturation, Lightness**:

```css
color: hsl(0 100% 50%);
color: hsl(240 100% 50%);
color: hsl(120 100% 25% / 0.8);
```

Many developers like HSL because it feels more intuitive than RGB.

### What the parts mean

1. **Hue**
   1. The basic position on the color wheel, usually in degrees.
   2. `0` is red, `120` is green, `240` is blue.

2. **Saturation**
   1. How vivid or grayish the color is.
   2. `0%` is gray, higher values are more colorful.

3. **Lightness**
   1. How light or dark the color appears.
   2. `0%` is black, `100%` is white.

### Why HSL became popular

HSL is often easier to reason about when making quick adjustments:

```css
/* same hue, different lightness */
--blue-40: hsl(220 80% 40%);
--blue-50: hsl(220 80% 50%);
--blue-60: hsl(220 80% 60%);
```

This *looks* appealing, but there is a catch: **HSL lightness is not perceptually uniform**. Colors with the same HSL lightness often do not appear equally bright. Yellow, for example, tends to look much brighter than blue at the same nominal lightness.

So HSL is intuitive, but it can be misleading when building balanced palettes.

## HWB

CSS also supports `hwb()`, which means **Hue, Whiteness, Blackness**:

```css
color: hwb(200 20% 10%);
```

This format is less common, but it can feel natural because it describes a hue mixed with white and black. It is useful in certain tooling and algorithmic color generation, though it has not become as mainstream as HEX, RGB, or HSL.

For many authors, `hwb()` is more of a nice-to-know syntax than an everyday tool.

## Lab and LCH

As CSS evolved, it began to support more perceptually oriented color spaces.

### `lab()`

`lab()` is based on the CIE Lab color space:

```css
color: lab(60% 30 20);
```

It uses:

1. **L** for lightness
2. **a** for the green–red axis
3. **b** for the blue–yellow axis

### `lch()`

`lch()` is a cylindrical representation of Lab:

```css
color: lch(60% 50 30);
```

It uses:

1. **L** for lightness
2. **C** for chroma
3. **H** for hue

This already feels more designer-friendly than `lab()`, because **chroma** and **hue** are easier to reason about than `a` and `b`.

Lab and LCH were important steps toward more perceptual CSS color handling, but in practice, **OKLab** and **OKLCH** are often even better choices.

## OKLab and OKLCH — the modern highlight ✨

If there is one color format worth learning now, it is **`oklch()`**.

### Why OKLCH matters

OKLCH is built on **OKLab**, a color space designed to be more perceptually uniform than older RGB/HSL-style approaches and often more practical than CIE Lab/LCH for interface and web design.

The big promise is simple:

> If you change a value in OKLCH, the visual result is more likely to match what you *expected*.

This is incredibly helpful for:

1. Building color scales
2. Creating themes
3. Keeping brightness consistent across hues
4. Producing smoother gradients
5. Making systematic adjustments with less guesswork

### The structure of `oklch()`

An OKLCH color looks like this:

```css
color: oklch(62% 0.18 264);
```

The three main components are:

1. **Lightness**
   1. Controls how light or dark the color appears.
   2. Usually the easiest value to tune for contrast and hierarchy.

2. **Chroma**
   1. Controls color intensity.
   2. Roughly similar to saturation, but more grounded in the color space.
   3. Higher values are more vivid, though the achievable maximum depends on hue.

3. **Hue**
   1. Controls the color family.
   2. Expressed as an angle.

Alpha can be added too:

```css
color: oklch(62% 0.18 264 / 0.7);
```

### Why designers and developers like OKLCH

#### 1. Lightness behaves more sensibly

With HSL, equal lightness values across different hues often look inconsistent. In OKLCH, lightness is much closer to perceived lightness.

That means this kind of palette is more reliable:

```css
--purple-40: oklch(40% 0.16 300);
--purple-55: oklch(55% 0.16 300);
--purple-70: oklch(70% 0.16 300);
```

Changing the first number tends to produce a more predictable visual ramp.

#### 2. Chroma is better than “saturation” for many tasks

“Saturation” in HSL can be deceptive. A color at `100%` saturation is not necessarily the most vivid or the most balanced version of that hue in practice.

In OKLCH, **chroma** is a more useful measure of colorfulness. If you reduce chroma, colors generally become more muted in a way that feels more natural:

```css
--brand-strong: oklch(60% 0.22 250);
--brand-soft:   oklch(60% 0.10 250);
```

These are easier to think about as “same lightness, same hue, different intensity.”

#### 3. Hue shifts are easier to manage

Because OKLCH is designed for perceptual consistency, rotating hue while holding other values steady often gives more balanced results than in older spaces.

This is valuable for generating semantic palettes:

```css
--info:    oklch(65% 0.14 240);
--success: oklch(65% 0.14 145);
--warning: oklch(65% 0.14 85);
--danger:  oklch(65% 0.14 25);
```

These colors are not magically perfect, but they often start from a much better baseline.

### Reading OKLCH intuitively

A useful way to think about it is:

```css
oklch(lightness chroma hue)
```

For example:

```css
oklch(70% 0.12 210)
```

can be read as:

1. A fairly light color
2. With moderate intensity
3. In the blue-cyan range

Over time, this becomes surprisingly ergonomic.

### Practical examples

#### A button palette

```css
:root {
  --button-bg: oklch(62% 0.17 260);
  --button-bg-hover: oklch(56% 0.17 260);
  --button-text: oklch(98% 0.01 260);
}
```

This works well because:

1. Hover is created mainly by lowering lightness.
2. Hue and chroma stay stable.
3. The relationship between states remains coherent.

#### A muted surface system

```css
:root {
  --surface-1: oklch(99% 0.01 250);
  --surface-2: oklch(96% 0.01 250);
  --surface-3: oklch(92% 0.02 250);
  --text-1: oklch(22% 0.02 250);
  --text-2: oklch(38% 0.02 250);
}
```

Notice how even “neutral” grays can carry a slight hue bias. That can make an interface feel warmer, cooler, softer, or more branded without becoming obviously colored.

### Important caveat: gamut limits

OKLCH is excellent, but not every combination of lightness, chroma, and hue can be displayed on a typical screen. In other words, some values fall **outside the available gamut**.

This matters because:

1. Very high chroma may not be possible for certain hues.
2. The browser may clamp or adjust out-of-range values.
3. A color that is mathematically valid may not render as expected on all devices.

So while OKLCH is powerful, it still has real-world limits. A practical workflow is to:

1. Start with reasonable chroma values
2. Preview in actual browsers
3. Use tooling that can warn about gamut issues

## Alpha and transparency

Most modern CSS color functions support alpha using slash syntax:

```css
rgb(0 0 0 / 0.5)
hsl(220 20% 20% / 0.3)
oklch(60% 0.15 240 / 0.4)
```

This is cleaner than older function pairs like `rgba()` and `hsla()`. While those names still exist historically, modern CSS treats alpha as a natural part of the same color function.

That consistency is one of the nice improvements in modern CSS syntax.

## Choosing the right format

There is no single correct format for every situation. A sensible rule of thumb is:

1. **Named colors**
   1. Good for simple cases and quick demos

2. **HEX**
   1. Good for compatibility, compactness, and copy-paste from design tools

3. **RGB**
   1. Good when you want direct channel control or explicit programmatic handling

4. **HSL**
   1. Good for quick human-readable adjustments
   2. Less reliable for perceptual consistency

5. **Lab/LCH**
   1. Good for more advanced perceptual workflows
   2. Often overshadowed by OKLab/OKLCH for modern UI work

6. **OKLCH**
   1. Excellent for design systems, palettes, theming, and more visually consistent adjustments
   2. Often the best modern choice when browser support fits your audience

## A few practical recommendations

If you’re building modern CSS today, here’s a pragmatic approach:

1. Use **OKLCH** when you are defining a system of colors.
   1. Especially for scales, semantic tokens, interactive states, and theme variants.

2. Use **HEX or RGB** when integration or tooling makes them more convenient.
   1. For example, some APIs, older docs, or design exports may still rely on them.

3. Be cautious with **HSL** for palette construction.
   1. It is intuitive, but its “lightness” can mislead you.

4. Always test actual contrast and rendering.
   1. No color space replaces accessibility checks.
   2. Perceptual consistency does not automatically guarantee sufficient contrast.

## Final thoughts

CSS color has evolved from a handful of convenient notations into a genuinely rich system. HEX, RGB, and HSL are still useful and widely relevant, but they reflect older ways of thinking about color—more tied to encoding or simplified mental models than to human perception.

**OKLCH** stands out because it bridges technical precision and design intuition. It gives you a way to adjust lightness, intensity, and hue in a manner that much more closely matches what your eyes expect to see. For modern UI work, that makes it one of the most compelling color formats CSS has ever offered.

If you only take one thing away, let it be this: **learn `oklch()`**. Even if you continue using HEX or RGB in some places, understanding OKLCH will make you better at choosing, adjusting, and organizing color across the board.