Breakpoint Seçimi: Cihaz Genişliği Değil, Düzenin Bozulduğu Nokta
Breakpoint tartışması çoğu zaman bir cihaz genişlikleri tablosuna dönüşüyor: şurası mobil, şurası tablet, şurası masaüstü. Tablo yazıldığı yıl doğruydu, ertesi yıl piyasaya çıkan cihazlarla birlikte kaydı. Daha dayanıklı soru şu: düzen tam olarak hangi genişlikte bozuluyor ve o an neyi değiştirmek gerekiyor?
Kırılma noktasını içerik söyler
Yöntem sıkıcı olduğu kadar güvenilir: tarayıcı penceresini yavaşça daraltın ve düzenin çirkinleştiği ilk anı not alın. Satır uzunluğu yetmiş beş karakteri aştığında, kart üç sütunda ezilmeye başladığında, menü başlığın üstüne bindiğinde bir genişlik değeri okursunuz. Breakpoint'iniz o değerdir. Bir cihazın adı değil.
Bu şekilde bulunan noktalar tuhaf sayılar çıkar, 640 yerine 610, 1024 yerine 970. Sorun değil. Yuvarlak sayılar tasarımcıyı rahatlatıyor, düzeni değil.
Birimi seçerken px yerine em kullanmanın somut bir karşılığı var. Varsayılan kök yazı boyu 16px olduğuna göre 48em tam olarak 768px'e denk gelir; fakat kullanıcı tarayıcı ayarından yazı boyunu 20px'e çıkardığında em tabanlı sorgu 960px'e kayar, px tabanlı sorgu yerinde kalır. Yani büyük yazı tercih eden kullanıcı, artık sığmayan bir düzenle baş başa bırakılır. Erişilebilirlik tarafında bu, üzerinde konuşulandan daha sık karşılaşılan bir hata.
Cihaz adına göre bölmenin sorunu
Yaygın tablolarda 500-1200px aralığı tek bir "tablet" bandı olarak geçiyor. Bu bant yedi yüz piksel genişliğinde: hem dikey duran 600px'lik bir tableti hem 1180px'lik küçük bir dizüstü ekranını aynı sekiz sütunlu düzene sokuyor. En geniş aralık, üzerinde en az düşünülen aralık haline geliyor.
Aynı tabloyu veren metinler bir paragraf sonra "analitiğinize bakıp kendi aralıklarınızı çıkarın" diyor. İkisi bir arada duramaz. Analitikten çıkaracaksanız tablo gereksiz, tabloyu kullanacaksanız analitik süs. Ziyaretçi genişlik dağılımınıza gerçekten bakarsanız çoğunlukla iki tepe görürsünüz: 360-430 civarı ve 1280-1512 civarı. Aradaki geniş boşluk, kaç tane ara breakpoint'e ihtiyacınız olduğunu da söyler.
Kaç tane yeter?
Üç, bazen dört. Sebebi estetik değil, çarpım: n breakpoint, her bileşen için n+1 düzen durumu demek. Yirmi bileşenli bir arayüzde altı breakpoint ile 140 ayrı durumu gözden geçirmeniz gerekir, üç breakpoint ile 80. Kimse 140 durumu test etmiyor, sadece test ettiğini sanıyor.
Pratikte listeye şunlar giriyor: gerçek cihazlarda kontrol (emülatör yazı tipi ve kaydırma davranışında yalan söyler), en uzun içerikle deneme (başlıklar tek satır varsayımıyla tasarlanıyor, gerçekte üç satır oluyor), bir de yatay modun unutulmaması. Rehberlerde sık geçen "CSS dosyasını değiştirmeden önce yedekleyin" maddesini listeye almadım (versiyon kontrolü varken yer kaplıyor).
Peki bileşen iki farklı genişlikte duruyorsa?
Aynı ürün kartı hem 320px'lik yan sütunda hem 900px'lik ana alanda görünüyorsa, viewport'a bakan bir media query bu ikisini ayırt edemez. Ekran 1400px'tir, kart ise dar sütundadır; sorgu geniş düzeni uygular ve kart bozulur. Media query'nin ölçtüğü şey pencere, kartın umursadığı şey kendi kabı.
Container query tam olarak bunu çözüyor. Kaba container-type: inline-size verip @container (min-width: 400px) yazdığınızda kart, sayfanın neresinde durduğuna göre kendi kararını verir. Bileşen tabanlı bir tasarım sisteminiz varsa breakpoint'lerin çoğu sayfa seviyesinden bileşen seviyesine iner ve global media query listesi üç satıra kadar kısalır.
Sırayı tersine çevirmek
Mobil öncelikli çalışmanın gerçek faydası felsefi değil, teknik. min-width ile yazdığınızda kurallar birikerek eklenir, max-width ile yazdığınızda birbirini iptal eder. İkincisinde CSS dosyası büyüdükçe hangi kuralın neden kazandığını kovalamakla vakit geçirirsiniz. Küçük ekranı temel alıp yukarı doğru eklemek, aynı zamanda içeriği önceliklendirmeye zorlar: 360px'e sığmayan şey, muhtemelen 1440px'te de gereksizdir.