Duyarlı Tasarımdan Bildirici Tasarıma: Kontrolü Tarayıcıya Bırakmak
Responsive tasarım, akışkan ızgara ve medya sorgusundan ibaret olduğu dönemde bir telafi yöntemiydi. Bugün elimizde gerçek yerleşim sistemleri var ama alışkanlık eski: her kırılım noktasını elle hesaplayan, tarayıcının zaten bildiği şeyleri yok sayan CSS yazmaya devam ediyoruz. Kontrolü nerede bırakmanın işe yaradığına, "tarayıcıya güven" tavsiyesinin nerede boşa düştüğüne bakalım.
Eskiden responsive iki tekniğe sığıyordu
Ethan Marcotte'nin Responsive Web Design makalesi yayımlandığında yerleşim için doğru dürüst bir araç yoktu. Tabloları yeni bırakmış, float'larla idare ediyorduk. Akışkan ızgaralar ve medya sorguları aslında birer yerleşim sistemi değildi; olmayan bir yerleşim sisteminin yerine geçen iki telafiydi.
Flexbox ve ardından CSS Grid geldiğinde değişen şey araç sayısı olmadı. İlk kez öğeleri sayfaya gerçekten yerleştirebildik: iki boyutlu düzen, alan bitince satır atlama, sabit ölçülü kutuyla akışkan kutuyu aynı satırda tutabilme, kasıtlı üst üste binme.
İçsel tasarım ne vaat ediyor
Jen Simmons bu yaklaşımı içsel web tasarımı (intrinsic web design) diye adlandırdı: yerleşim sistemlerini gerçekten yerleşim için kullanmak. Tanım ilk duyuşta fazla mütevazı geliyor, çünkü kulağa bir teknik değil bir temenni gibi geliyor.
Asıl kazanç başka yerde. İçsel tasarım, içeriğin ölçüsünü önceden bilmeden düzen kurmayı mümkün kılıyor. Ürün adının kaç karakter olacağını, çevirinin Almancaya geçince ne kadar uzayacağını, kullanıcının başlığı kaç puntoda göreceğini bilmiyorsunuz. Eski yöntemde bu bilinmezliğin her biri ayrı bir medya sorgusuydu; şimdi tek bir kısıt.
Tarayıcıya güven, ama hangi konuda
Heydon Pickering bu düzenlere algoritmik yerleşimler diyor, haklı da: web zaten algoritmik çalışıyor. En sade sayfada bile satır sonunu tarayıcı hesaplıyor, üstelik sizin göremeyeceğiniz koşullara bakarak. Andy Bell'in "tarayıcının akıl hocası olun, mikro yöneticisi değil" cümlesi de bu yüzden bu kadar çok alıntılanıyor.
Yine de cümle sık sık tembelliğin kılıfı oluyor. Tarayıcı cihazı, görüntü alanını, kullanıcının yardımcı teknolojisini, hareket ve tema tercihini biliyor. İçeriğinizin hangi cümlesinin ilk ekranda görünmesi gerektiğini bilmiyor. Tabloda hangi sütunun daralınca feda edilebileceğini de bilmiyor. Güvenmek, kısıt vermeyi bırakmak değil; doğru kısıtı verip sonrasına karışmamak.
Bildirici tasarım ve clamp() satırının okunmayan yarısı
Jeremy Keith'in bildirici tasarım dediği geçiş tam olarak bu: tarayıcıya "nasıl" değil "ne" istediğinizi söylemek, çıktıyı değil girdiyi tasarlamak. Akışkan tipografi bunun en görünür örneği ve clamp() ile tek satıra iniyor. Akışkan ölçeği, medya sorgularıyla basamaklandırılmış font-size setlerinden daha güvenilir buluyorum: basamaklı çözüm iki kırılım noktası arasında hep bir öncekinin boyutunda takılı kalır, akışkan olan yalnızca uçlarda ayar ister.
Ama dolaşımdaki örnek satırlar çoğu zaman çalışmıyor. Şu, blog yazılarında en çok kopyalanan biçim:
font-size: clamp(1rem, calc(1rem + 2.5vw), 6rem);Alt sınır hiçbir zaman devreye girmiyor. 2.5vw her genişlikte sıfırdan büyük olduğu için orta değer 1rem'in altına inemiyor; 320 piksellik bir telefonda bile ölçek 1rem + 8px, yani varsayılan ayarda 24 piksel. Üst sınır da pratikte yok: 6rem'e ulaşmak için 2.5vw'nin 80 piksel olması, yani görüntü alanının 3200 piksele çıkması gerekiyor. Geriye adı clamp olan ama iki ucundan da bağlı olmayan bir formül kalıyor.
Gövde metni için işleyen bir sürüm şuna benziyor:
font-size: clamp(1rem, 0.92rem + 0.4vw, 1.25rem);Bu satır 320 pikselde tam olarak 1rem'e oturuyor, 1320 pikselde tavana değiyor, arada doğrusal ilerliyor. Taban ve tavan rem cinsinden olduğu için kullanıcının kök yazı tipi ayarıyla birlikte de ölçekleniyor. Bir clamp satırı yazdığınızda iki ucun hangi genişlikte devreye girdiğini hesaplayın; hesap tutmuyorsa o satır sadece süs.
Aşamalı geliştirme hâlâ ucuz
Sınırlı desteğe sahip özellikleri beklemeye gerek yok. Görünüm geçişleri gibi bir şey tek satırla açılıyor:
@view-transition { navigation: auto; }Desteklemeyen tarayıcıda hiçbir şey bozulmuyor, destek geldiğinde kod zaten yerinde. Aynı mantık mantıksal özellikler için de geçerli: margin-inline ve border-inline-start, sağ-sol ikilisinden hem daha sezgisel hem de siteyi Arapçaya çevirdiğiniz gün tek tek düzeltilecek yüzlerce kuralı baştan siliyor.
rem'i piksele çevirmeyi bırakınca
Teknik tarafı bir yana, asıl değişim zihinsel olanı. 1rem'in 16 piksel olduğu bir varsayım, garanti değil. Kullanıcının tarayıcısında ne ayarladığına bağlı olarak herhangi bir sayı olabilir. Yani rem ile çalışıp sonra kafanızda piksele çeviriyorsanız, birimi kullanıyor ama faydasını almıyorsunuz.
Kök yazı tipi boyutunu bilmediğinizi kabul ettiğiniz anda somut sayılarla düşünemez hale geliyorsunuz. Geriye oranlar kalıyor. Düzen de, boşluk da, kart yükseklikleri de metnin kendi ölçüsüne bağlanıyor. Bu kısıtlayıcı değil, tam tersine yerleşimi kullanıcının 64 piksellik varsayılanında da ayakta tutan şey.
Ve kararı devrettiğiniz şey aslında tarayıcı değil, kullanıcı. Karanlık temayı, azaltılmış hareketi, dokunmatik hedef boyutunu tercihleri üzerinden okuyup buna göre davrandığınızda ortaya çıkan şey daha esnek bir site değil, kullanıcının kendi koşullarına uyan bir site oluyor. Yazı tipini neden 64 piksele çektiğini bilmenize gerek yok; çektiğini bilmeniz yeterli.