Konu Başlıkları
Yükleniyor...

Mobile-First CSS ve Kapalı Aralık Medya Sorguları

Mobile-First mi, Kapalı Aralık Medya Sorguları mı?

Mobile-first uzun süre tartışmasız doğru kabul edildi: önce dar ekranı yaz, sonra min-width ile genişlet. Peki bu sıra gerçekten bir zorunluluk mu, yoksa 2010'ların tarayıcı ve bağlantı koşullarından kalma bir alışkanlık mı? Kapalı aralık medya sorguları ve media attribute ile bölünmüş stil dosyaları aynı işi farklı maliyetlerle yapıyor.

Mobile-first'ün asıl vaadi sıralama değil, sadelik

Yöntem basit: dar ekranın stilini temel al, min-width ile büyüt. Faydası da ekran boyutundan çok karar verme biçimiyle ilgili. Dar ekranda yer olmadığı için hangi öğenin gerçekten gerektiğine baştan karar vermek zorunda kalırsın.

Sorun ikinci adımda başlıyor. Her yeni breakpoint bir öncekinin üstüne yazıyor, yani bir bileşenin nihai görünümü tek bir yerde değil, üç dört kuralın toplamında duruyor. Taban katmanda padding'i değiştirdiğinde üstteki her aralığı yeniden gözden geçirmen gerekir. Bu zincir kaç halkaya kadar taşınabilir?

Kapalı aralık: override yerine tekrar

Alternatif, her aralığı kendi bağlamında yazmak. min-width ve max-width birlikte, üst üste binmeyen aralıklar:

.blok { @media (max-width: 767px) { padding: 20px; } @media (min-width: 768px) and (max-width: 1023px) { padding: 40px; } @media (min-width: 1024px) { padding: 64px; } }

Burada hiçbir kural diğerini ezmiyor, her ekran genişliğinde tam olarak bir kural eşleşiyor. Bileşenin davranışını anlamak için tek bloğa bakmak yetiyor, spesifiklik savaşı da ortadan kalkıyor.

Bedeli tekrar. Üç aralık tanımladıysan, aralıklar arasında hiç değişmeyen bir özelliği ya üç kere yazarsın ya da bloğun dışında bırakırsın. Doğrusu ikincisi: kapalı aralık yalnızca gerçekten farklılaşan özellikler için doğru araç, ortak olan ne varsa medya sorgusunun dışında tek yerde kalmalı. Bunu karıştıran ekip, mobile-first'ün override zincirinden kaçarken üç katına çıkmış bir tekrar tablosuyla kalıyor.

Bir tema devralmıştım, tek bir butonun padding'i beş ayrı breakpoint'te override ediliyordu; ortak değerleri dışarı alıp kalanı iki kapalı aralığa indirince aynı buton üç kurala düştü.

CSS'i bölmek ne kazandırır, ne kazandırmaz

HTTP/2 sonrası yaygınlaşan öneri, stilleri ekran aralığına göre ayrı dosyalara bölüp media attribute'uyla bağlamak:

  • <link rel="stylesheet" media="screen and (max-width: 767px)" href="mobile.css">
  • <link rel="stylesheet" media="screen and (min-width: 768px) and (max-width: 1023px)" href="tablet.css">
  • <link rel="stylesheet" media="screen and (min-width: 1024px)" href="desktop.css">

Sık atlanan nokta şu: eşleşmeyen dosya indirilmez değil, indirilir. Tarayıcı media sorgusunu değerlendirir, eşleşmeyen stil dosyasını render'ı bloklamayan düşük öncelikli bir istek olarak kuyruğa alır ve yine de çeker. Kazanç bant genişliğinde değil, ilk boyamayı bekleten kritik yolda. Mobilde ölçtüğünde ilk içerikli boyama süresi düşer, transfer edilen toplam bayt aşağı yukarı aynı kalır.

Bu ayrımı bilmeden ölçüm yapan biri yanlış sonuca varır. "Böldüm ama toplam CSS boyutu değişmedi, demek ki işe yaramamış" cümlesi tam buradan çıkıyor. Doğru metrik boyut değil, stil dosyasının render'ı ne kadar beklettiği.

Hangisi hangi projede

Blog, tanıtım sayfası, dokümantasyon gibi içerik ağırlıklı ve bileşenleri ekranlar arası fazla değişmeyen siteler için mobile-first zinciri hâlâ en ucuz yol. Yazması hızlı, kural sayısı az, override derinliği zaten iki üçü geçmiyor.

Bileşenin dar ekranda tamamen farklı bir yapıya dönüştüğü yerlerde, mesela masaüstünde tablo olan bir listenin mobilde kart yığınına dönmesinde, kapalı aralık daha dürüst bir model. İki farklı düzen zaten iki farklı koddur; birini diğerinin override'ı gibi göstermek sadece okumayı zorlaştırır.

Dosya bölmeyi ise sona bırakmak gerekiyor. Kapalı aralıklara geçmiş, ortak stilleri ayıklamış bir kod tabanında bölme doğal olarak kolaydır; karışık bir override zincirini dosyalara bölmeye çalışmak ise sadece karışıklığı üç dosyaya yayar.

Kaynaklar