Beklenmeyen İçin Tasarlamak: Viewport Yerine İçerik ve Durum
Zeldman'ın cümlesi hâlâ rahatsız edici: bir ürünün ömrü, henüz hayal etmediğiniz ortamlarda ve daha üretilmemiş cihazlarda çalışabilmesine bağlı. Sabit 960 piksellik maketlerden bugüne öğrendiğimiz şey, ekran ölçüsüne göre tasarlamanın er ya da geç tıkandığı. Asıl mesele arayüzü viewport'a değil, içeriğe ve kullanıcının içinde bulunduğu duruma bağlamak.
960 pikselden medya sorgusuna
Yıllarca Photoshop'ta 960 piksel genişliğinde sabit maketler çizdik. Sabit genişlik, sabit yükseklik, mutlak konumlandırma. 2010'da Ethan Marcotte responsive web design'ı tarif ettiğinde bunun bir teknik değil bir planlama meselesi olduğu hemen anlaşılmadı. Projenin son haftasında birkaç medya sorgusu iliştirerek sabit bir maketi duyarlı hale getirmeye çalışan herkes aynı duvara tosladı. Yüzde tabanlı yerleşim ve akışkan görseller işi kurtardı, ama beraberinde yeni bir bakım yükü geldi.
Kırılma noktaları neden çoğalıp duruyor
Masaüstü, tablet, mobil ile başladı. Sonra phablet, geniş ekran, katlanabilir cihazlar eklendi. Sorun kırılma noktasının sayısı değil, neye bağlandığı: medya sorgusu her zaman viewport'u ölçer, bileşenin içinde durduğu kutuyu değil.
Bedeli çarpım olarak büyür. Aynı kartı ana içerikte, kenar çubuğunda, footer'da ve bir modalda kullanıyorsanız ve beş kırılma noktanız varsa, viewport'a bağlı yaklaşımda yirmi ayrı durumu tanımlayıp gözden geçirmeniz gerekir. Kart üç genişlik eşiğinde biçim değiştiriyorsa ve bu eşikleri kendi kutusuna göre ölçüyorsanız, sayı bağlamdan bağımsız olarak üçte kalır. Yeni bir yerleşim alanı açmak ilk durumda maliyeti bir kat daha artırır, ikincisinde neredeyse bedavadır.
Container query bileşene kendi sorusunu sordurur
Container query, elemanın kendi kapsayıcısının ölçüsüne göre biçimlenmesini sağlar. Böylece bir bileşen nerede kullanıldığını bilmek zorunda kalmaz, sadece kendisine ne kadar yer verildiğine bakar. Bileşen kütüphanesi tutan ekipler için kazanç doğrudan: kartın stil dosyası artık sayfa şablonuyla ilgili varsayım taşımaz.
Yine de kapsayıcı genişliği tek başına yeterli bir sinyal değil. 320 piksellik bir kutuya sığan şey, içindeki başlığın üç kelime mi otuz kelime mi olduğuna göre değişir. Ölçüye bakan her yaklaşım bu noktada içerik hakkında bir tahmin yürütür.
Intrinsic layout: alan ne veriyorsa
Jen Simmons'ın intrinsic layout dediği şey yeni bir teknoloji değil, eski ve yeni CSS'in birlikte kullanılması. fr birimi, minmax(20ch, 1fr) gibi tanımlar ve auto-fit ile sütun sayısını kırılma noktası yazmadan içeriğe bırakabilirsiniz. Subgrid ise kardeş kartların başlık ve buton hizasını, içerik uzunlukları farklı olsa bile korur.
Bu yaklaşımın Bootstrap türü framework'lerde hazır sınıflara dönüşmemiş olması yayılmasını yavaşlatıyor. Framework kısa vadede hız verir, uzun vadede tasarımı kendi ızgarasının çözebildiği şeylerle sınırlar. Uzun ömürlü bir ürün arayüzü ve tekrar eden bir bileşen diliniz varsa intrinsic yaklaşım kendini birkaç ay içinde amorti eder. İki haftada teslim edilecek bir tanıtım sitesinde framework'ü açıp geçmek daha doğru karar.
İçerik sabit değildir
Başlık uzar, görsel gelmez, çeviri iki katına çıkar. Tasarımın buna çökerek değil esneyerek cevap vermesi gerekir. min(), max() ve clamp() tipografiyi ve boşlukları alt ve üst sınır arasında serbest bırakır.
Bu fonksiyonlar sık sık "logical properties" başlığı altında anılıyor, oysa ikisi ayrı şey. clamp() bir matematik fonksiyonudur; logical properties ise margin-inline-start, padding-block gibi yönü fiziksel eksene değil yazı yönüne bağlayan özelliklerdir. Karışıklık masum değil: siteye Arapça bir sürüm eklendiğinde yerleşimi kendiliğinden çeviren ikincisidir, clamp() değil.
Durum da bir tasarım girdisi
Kullanıcı sadece bir ekran ölçüsü değil. Tren tünelinde, güneş altında, sayaçlı bir hatta olabilir. srcset ile doğru boyuttaki görseli, loading="lazy" ile ertelenebilir olanı, preload ile ilk boyamayı bekleten kaynağı ayırmak bu yüzden tasarım kararıdır, optimizasyon detayı değil.
Medya sorgularının tercih tarafı da işe yarar hale geldi. prefers-color-scheme ve prefers-reduced-motion bugün yaygın destekli, ikisini de bugün yazabilirsiniz. prefers-reduced-data aynı olgunlukta değil, dolayısıyla veri tasarrufunu ona havale etmek yerine varsayılan sayfayı zaten hafif tutmak gerekir. Bir özelliği ancak yokluğunda deneyim bozulmuyorsa kullanın.
Nereye yaslanmalı
Viewport ölçüsü hâlâ bir bilgi, ama artık en zayıf bilgi. Bileşenin kendi alanı ondan iyi, içerikteki gerçek uzunluk ve kullanıcının bildirdiği tercih ondan da iyi. Bir kırılma noktası yazmadan önce sormaya değer soru şu: bu kural gerçekten ekranla mı ilgili, yoksa o an oraya ne sığdığıyla mı?
Kaynaklar