OKLCH’de Lightness Tuzağı: Palet Kurarken Dikkat

OKLCH’de “lightness” değerini sabitleyip yalnızca onu tararak palet kurmak en kolay yol gibi görünür, ama chroma’yı sabit tutarsanız bazı ton-lightness kombinasyonları ekranın gösterebileceği renk aralığının (gamut) dışına taşar ve tarayıcı bunu sessizce kırpar. Bu yazıda UX Collective’in OKLCH açıklamasından yola çıkıp bu tuzağın nasıl oluştuğunu gerçek örneklerle gösteriyoruz.

OKLCH Nedir, HSL’den Farkı Ne?

OKLCH, bir rengi L (lightness/parlaklık), C (chroma/doygunluk) ve H (hue/ton açısı) olmak üzere üç eksenle tanımlayan, algısal olarak düzgün (perceptually uniform) bir renk uzayı. UX Collective’te yayınlanan “OKLCH, explained for designers” yazısında Samuel Wong, HSL’nin en büyük sorununu şöyle özetliyor: aynı lightness değerine sahip iki HSL rengi görsel olarak eşit parlaklıkta görünmeyebiliyor, çünkü algılanan parlaklık hue’ye göre değişiyor.

OKLCH bu sorunu çözer: oklch(0.65 0.15 250) ile oklch(0.65 0.15 60) — biri mavi, diğeri sarı — insan gözüne gerçekten eşit parlaklıkta görünür. HSL’de aynı L değerinde sarı, maviden belirgin şekilde daha parlak algılanır. Bu fark, OKLCH’yi tema/tint-shade skalaları ve karanlık mod hesaplamaları için cazip kılan temel özellik.

UX Collective’in Anlattığı: Lightness’le Ölçeklemenin Cazibesi

Wong’un makalesindeki pratik örneklerden biri, bir marka renginin karanlık mod varyantını CSS’in oklch(from ...) göreli renk sözdizimiyle otomatik hesaplamak. Chroma ve hue sabit kalırken yalnızca lightness değiştirildiği için sonuç, orijinal renkle aynı “kimlikte” ama farklı parlaklıkta bir ton oluyor:

:root {
  --brand: oklch(56% 0.18 250);
}

.dark {
  /* aynı hue ve chroma, sadece lightness değişiyor */
  --brand: oklch(from var(--brand) calc(l / 2 + 0.2) c h);
}

Bu yaklaşım gerçekten işe yarıyor — ama yalnızca chroma değeri, hedef lightness’ta o hue için hâlâ geçerliyse. İşte tam burada makalenin değinmediği, ama pratikte herkesin er ya da geç çarptığı bir sınır devreye giriyor.

Sorun: Sabit Chroma + Değişen Lightness Neden Kırılıyor?

Geliştirici Chris Coyier, “Two Things That are Not Great About OKLCH” yazısında somut bir örnek veriyor: oklch(68% 0.25 150) geçerliyken, sadece hue değerini 150’den 152’ye çıkarmak rengi geçersiz hâle getirebiliyor — OKLCH.com’un renk seçicisi bu koordinatların artık “var olmadığını” gösteriyor. Sorunun kaynağı OKLCH’nin silindirik yapısı: L-C-H koordinat uzayında pek çok sayısal kombinasyon, hiçbir ekranın gösteremeyeceği bir noktaya denk düşüyor.

Evil Martians’ın “OKLCH in CSS” yazısı bunu daha genel biçimde doğruluyor: “not all combinations of L, C, and H will result in colors that are supported by every monitor.” Yani her hue’nin, her lightness seviyesinde farklı bir maksimum chroma sınırı var — bu sınırın üstüne çıktığınızda tarayıcı rengi otomatik olarak en yakın geçerli renge “kırpar” (gamut clipping).

Bu kırpma sessiz gerçekleşiyor, hata vermiyor. Aşağıdaki görselde hue 150° (yeşil) ve sabit chroma 0.2 ile lightness 0.3’ten 0.9’a taranmış gerçek bir OKLCH skalası var — tarayıcı bunu doğrudan render ediyor:

Yüksek lightness ucunda renk, beklenen doygun yeşil yerine daha soluk bir tona “yapışıyor” — çünkü o lightness seviyesinde chroma 0.2 artık gamut sınırının dışında ve tarayıcı en yakın geçerli değere yuvarlıyor.

Neden Bazı Hue’ler Daha Toleranslı?

MDN’nin oklch() referansına göre her hue’nin fiziksel olarak ulaşabileceği maksimum chroma değeri farklı: belirli bir lightness’ta koyu maviler çok yüksek chroma’ya çıkabilirken, aynı lightness’taki yeşil veya kırmızı tonlar çok daha erken sınıra çarpar. Bu, insan görme sisteminin fizyolojisinden kaynaklanan bir kısıt, tasarım tercihi değil.

Aşağıdaki görsel aynı lightness (0.7) değerinde mavi (260°) ve yeşil (140°) hue’lerini artan chroma ile karşılaştırıyor — ikisi de gerçek tarayıcı render’ı:

Mavi sütun chroma 0.30’a kadar görünür şekilde koyulaşmaya devam ederken, yeşil sütun 0.25’ten itibaren pratikte aynı renkte donuyor — çünkü o noktadan sonraki her adım gamutun dışına düşüp aynı sınır rengine kırpılıyor.

Doğru Yaklaşım: Chroma’yı da Lightness’a Göre Ayarlayın

Pratik çözüm, chroma’yı sabit bir sabit olarak değil, lightness’a bağlı bir değişken olarak ele almak. Uçlarda (çok koyu ya da çok açık tonlarda) chroma zaten fiziksel olarak sınırlı olduğu için, skalayı oluştururken chroma’yı da orta noktadan uçlara doğru azaltmak gerekiyor:

• Chroma’yı lightness eksenine göre kademeli düşürün — orta lightness’ta tepe, uçlarda düşük chroma.
• Tek bir chroma değerini bütün skalaya kopyalamayın — Evil Martians’ın da belirttiği gibi bu, “delikli” (bazı adımların kırpıldığı) bir skala üretir.
• Geniş gamutlu ekranlar için ayrı katman ekleyin — Evil Martians, @media (color-gamut: p3) sorgusuyla P3 destekleyen ekranlara daha yüksek chroma değerleri veren bir yöntem öneriyor.
• Gamut-farkında araçlarla doğrulayın — oklch.com’un renk seçicisi geçersiz kombinasyonları görsel olarak işaretliyor; stylelint-gamut eklentisi de derleme sırasında P3 dışı renkleri tespit ediyor.

Evil Martians’ın P3 katmanı örneği şöyle görünüyor — temel renk sRGB ekranlar için güvenli kalırken, geniş gamut ekranlarda chroma artırılıyor:

.accent {
  background: oklch(0.7 0.15 145);
}

@media (color-gamut: p3) {
  .accent {
    background: oklch(0.7 0.19 145);
  }
}

Aynı mantığı bir tint-shade skalasına uyguladığınızda fark, gözle görülür hâle geliyor. Aşağıda hue 250° (mavi-mor) için iki skala var: üstteki sabit chroma (0.22) ile, alttaki ise uçlara doğru chroma’yı azaltarak oluşturuldu — ikisi de gerçek tarayıcı render’ı:

Üst sıradaki fark subtil çünkü kırpma genelde sessiz ve kademeli oluyor — tam da bu yüzden fark edilmeden üretime çıkması kolay. Alt sıradaki skalada chroma, lightness’la birlikte kasıtlı olarak değişiyor ve sonuç daha tutarlı bir görsel ritim veriyor.

Kod Örneği: Chroma’ya Duyarlı Bir Palet Ölçeği

Yukarıdaki “alt sıra” skalasının CSS custom properties hâli şöyle. Chroma değerleri 0.06 ile 0.22 arasında, lightness’a göre elle ayarlandı — otomatik bir formül değil, gamut’a göre kalibre edilmiş sabit adımlar:

:root {
  --scale-100: oklch(0.30 0.10 250);
  --scale-200: oklch(0.40 0.16 250);
  --scale-300: oklch(0.50 0.20 250);
  --scale-400: oklch(0.60 0.22 250); /* tepe chroma */
  --scale-500: oklch(0.70 0.19 250);
  --scale-600: oklch(0.80 0.13 250);
  --scale-700: oklch(0.90 0.06 250);
}

Bu, Tailwind CSS v4’ün varsayılan renk paletinde izlediği mantıkla da örtüşüyor: Tailwind’in resmi v4 duyurusuna göre tüm varsayılan palet RGB’den OKLCH’ye taşındı ve sRGB’nin sınırladığı yerlerde daha canlı renkler üretmek için geniş gamuttan yararlanılıyor — yani chroma, sabit bir sayı değil, her ton/hue kombinasyonu için ayrı ayrı kalibre edilmiş durumda.

İlgili Yazılar

Renk ve CSS ekseninde sitede daha önce ele aldığımız birkaç konu bu yazıyı tamamlıyor. Karanlık mod hesaplamalarını OKLCH ile otomatikleştirmeden önce “Dark Mode Toggle’ında ‘Sistem’ Seçeneği Gerçekten Gerekli mi?” yazısına göz atmak faydalı olabilir. CSS’in yakın gelecekte kazanacağı yeni yeteneklerle ilgileniyorsanız “CSS’e ‘Navigasyon Eşleştirme’ Geliyor: @navigation ve @location Taslağı” yazımız da bu serinin bir parçası. Tarayıcıya özgü CSS tuhaflıklarıyla uğraşmayı seviyorsanız “iOS Safari’de Site Arka Planını Çentiğin Altına Uzatan CSS Hilesi” de benzer bir “tarayıcı gerçek dünyada ne yapıyor” bakış açısı sunuyor.

Sıkça Sorulan Sorular

OKLCH tüm güncel tarayıcılarda destekleniyor mu?

Evet, oklch() Chrome 111, Edge 111, Firefox 113 ve Safari 15.4 sürümlerinden itibaren destekleniyor — bu da güncel tarayıcı kullanıcılarının büyük çoğunluğunu kapsıyor. Eski tarayıcılar için CSS cascade’de önce bir hex/HSL değeri, ardından oklch() değeri tanımlayarak güvenli bir geri dönüş (fallback) sağlayabilirsiniz.

Sabit chroma her zaman sorun çıkarır mı?

Hayır. Bazı hue’lerde ve orta lightness aralıklarında sabit bir chroma değeri, tüm skala boyunca gamut içinde kalabilir. Sorun özellikle çok açık veya çok koyu lightness uçlarında ve chroma değeri o hue için zaten sınıra yakın seçildiğinde ortaya çıkıyor.

Bir OKLCH renginin gamut dışına taştığını nasıl anlarım?

oklch.com üzerindeki renk seçici geçersiz kombinasyonları görsel olarak işaretliyor. Chrome, Firefox ve Safari’nin geliştirici araçlarındaki renk seçiciler de OKLCH değerlerini doğrudan düzenlemenize ve gamut dışı değerleri görmenize izin veriyor; derleme aşamasında otomatik denetim için stylelint-gamut gibi eklentiler kullanılabilir.

Tailwind CSS’in varsayılan paleti OKLCH mi kullanıyor?

Evet. Tailwind CSS v4 ile birlikte varsayılan renk paletinin tamamı OKLCH’ye taşındı; isim ve ton numaraları (ör. red-500) aynı kalsa da bazı tonların gerçek renk değeri v3’e göre değişti, çünkü palet artık geniş gamuttan yararlanıyor.