Tarayıcıda Gelecek Diye Sunulan Özelliklerin Çoğu Zaten Burada
Tarayıcı geleceği üzerine yazılan listelerin ortak bir tuhaflığı var: saydıkları özelliklerin çoğu çoktan gelmiş. Sayfa kaydırılırken sabit kalan başlık, ölçeklenebilir vektör grafik, çevrimdışı çalışma. Bunlar beklenen şeyler değil, yıllardır kullanılabilir olan şeyler. Asıl soru hangi yeniliğin geleceği değil, hangisinin arayüz kararını bugün değiştirdiği.
Zaten Gelmiş Olanı Gelecek Sanmak
Uzun sayfalarda başlığın ya da menünün kaydırma sırasında yerinde kalması hâlâ "beklenen özellik" diye sunuluyor. Oysa position: sticky bütün güncel tarayıcılarda çalışıyor ve tek satırlık bir CSS kuralı. SVG için de durum aynı: HTML5'ten daha eski bir standart, interaktif grafik ve harita işini yıllardır görüyor. Çevrimdışı çalışma, önbellekleme ve önden yükleme ise service worker'larla çözülmüş, olgunlaşmış bir konu.
Bu ayrım boş bir titizlik değil. Bir özelliği "yakında gelecek" rafına koyduğunda tasarım kararını da ertelersin. "Zaten var" dediğinde ise bu hafta uygularsın.
Bağlantıya Göre Uyarlanan Arayüz Ne Kadar Mümkün?
Yavaş bağlantıdaki kullanıcıya daha hafif bir arayüz göstermek makul bir fikir. Peki tarayıcı bunun için sana ne veriyor? Network Information API üzerinden navigator.connection.effectiveType okunabiliyor, ama destek büyük ölçüde Chrome tarafında kalmış durumda; Safari ve Firefox bu bilgiyi vermiyor. Ziyaretçilerinin bir bölümünde sinyal hiç gelmeyecekse, arayüzün davranışını tamamen o sinyale bağlamak kırılgan bir tercih olur.
Video kalitesini bağlantıya göre ayarlamak da aslında tarayıcının değil oynatıcının işi. HLS ve DASH bunu yıllardır yapıyor, tarayıcıdan beklenen yeni bir yetenek değil.
Daha sağlam bir dayanak var: kullanıcı cihazında veri tasarrufu modu açıksa istekle birlikte Save-Data başlığı geliyor. Bunu sunucuda okuyup görselin hafif varyantını dönersin, üçüncü parti bir servise gerek kalmaz.
PWA Vaadiyle Gerçeği Arasındaki Boşluk
Web uygulamalarının bildirim gönderebilmesi uzun süre yalnızca masaüstünün ve Android'in ayrıcalığıydı. iOS tarafında Safari 16.4 ile web push geldi, ama koşullu geldi: kullanıcı siteyi ana ekrana eklemediği sürece bildirim gönderemezsin.
Peki kaç kişi bir siteyi ana ekrana ekliyor? Bunu ölçmeden varsaymamak gerekir, çünkü cevap sitenin kullanım sıklığına göre dramatik biçimde değişir. Pratik sonuç şu: bildirimi akışın taşıyıcısı yapma. Kullanıcının işini bitirebilmesi bildirime bağlıysa, o kullanıcıların bir kısmı işi hiç bitiremez. Bildirim hatırlatıcı olarak iyi çalışır, tek kanal olarak değil.
Arayüz Kararını Gerçekten Değiştirenler
Gerçekten yeni olan ve tasarımın nasıl kurulduğunu etkileyen birkaç şey var. Konteyner sorguları (@container), bileşenin ekran genişliğine değil içine yerleştirildiği kutunun genişliğine göre davranmasını sağlıyor. Aynı kart bileşenini hem geniş bir listede hem dar bir kenar çubuğunda kullanıyorsan, medya sorgularıyla kurulmuş duyarlı tasarım mantığının epey bir kısmı gereksizleşiyor.
CSS'in :has() seçicisi ebeveyni çocuğuna göre seçmeyi mümkün kıldı. Bir alana hata sınıfı eklemek için JavaScript yazılan durumların çoğu tek bir seçiciye indi. View Transitions ise sayfa geçişlerini ayrı bir animasyon kütüphanesi kurmadan yapılabilir hale getirdi.
Peki bu geçişler herkese aynı gösterilmeli mi? Hayır. Hareket duyarlılığı olan kullanıcılar için prefers-reduced-motion yıllardır orada duruyor ve geçiş animasyonu eklerken bu sorguyu yazmamak, animasyonu hiç eklememekten daha kötü bir sonuç üretir. Erişilebilirlik tarafında beklenecek yeni bir API yok; klavye gezintisi, odak sırası ve ekran okuyucu desteği tarayıcının gelecek sürümüne değil, senin işaretlemene bağlı.
Hangi Listeye Bakmalı
Tarayıcı geleceğini merak ediyorsan trend yazıları yerine destek tablolarına bakmak daha çok iş görür. Bir özelliğin ne zaman geleceğini tahmin etmek yerine, kendi ziyaretçilerinin kullandığı tarayıcılarda bugün çalışıp çalışmadığına bakarsın. Aradaki fark, kararı ertelemekle uygulamak arasındaki fark.