Responsive tasarım

İlan metninde geçen "responsive" kelimesinin karşılığı bu derstir. Duyarlı tasarım, ekran boyutuna göre ayrı siteler yapmak değil; tek bir düzenin akıp uyum sağlamasıdır. Bugün bu işin büyük kısmı medya sorgusu bile gerektirmez — 8, 9 ve 10. derslerde gördüğün clamp(), minmax(), auto-fit ve flex-wrap zaten esnektir. Medya sorgusu düzenin biçim değiştirmesi gerektiğinde devreye girer. Bu ders kırılma noktasının nasıl seçildiğini, mobil-öncelikli yazmanın neden pratik olduğunu, esnek görselleri ve modern karşılığı olan kapsayıcı sorgularını anlatıyor.

01Ne öğreneceksin

02Önce viewport, sonra her şey

1. ve 2. derslerde geçmişti; burada nedenini görüyoruz. Mobil tarayıcılar, duyarlı olmayan eski siteler düzgün görünsün diye sanal bir görünüm alanı kullanır: sayfayı 980 CSS pikseli genişliğinde çizip ekrana sığacak kadar küçültürler. Sonuç, uzaktan bakılan bir masaüstü sayfasıdır ve tüm medya sorguların "geniş ekran" dalını çalıştırır.

<meta name="viewport" content="width=device-width, initial-scale=1">

Bu satır "görünüm alanı cihazın gerçek genişliği olsun, ölçek 1'de başlasın" der. Duyarlı tasarımın ön koşuludur — bu satır olmadan yazdığın hiçbir medya sorgusu mobilde beklediğin gibi çalışmaz.

content içine eklenen iki değer bilinmelidir ve ikisi de erişilebilirlik ihlalidir:

<!-- YAZMA: kullanıcının yakınlaştırmasını engeller (WCAG 1.4.4) -->
<meta name="viewport" content="width=device-width, maximum-scale=1, user-scalable=no">

Görme güçlüğü olan kullanıcılar sayfayı parmakla büyütür; bunu kapatmak, ölçülebilir bir erişilebilirlik hatasıdır ve denetimlerde doğrudan düşer. Modern iOS bu ayarı zaten yok sayar.

CSS pikseli ≠ cihaz pikseli

width: 320px yazdığında bu fiziksel piksel değildir. Modern telefonlar bir CSS pikselini 2, 3 hatta 4 fiziksel pikselle çizer; bu orana cihaz piksel oranı (DPR) denir. Pratik sonuçları:

• Telefonun "1170 piksel" reklamı yapılan ekranı CSS'te 390 px genişliğindedir.
• Görseller bu yüzden 2x/3x çözünürlükte sunulur — srcset'in varlık sebebi.
• 1px kenarlık yüksek DPR'li ekranda saç teli inceliğinde görünür; tasarımcının "daha kalın olsun" demesinin sebebi budur.
• JavaScript'ten window.devicePixelRatio ile okunur.

03Medya sorguları

/* Klasik yazım */
@media (min-width: 900px) { … }
@media (max-width: 899.98px) { … }
@media (min-width: 600px) and (max-width: 899px) { … }
@media (orientation: landscape) { … }
@media print { … }

/* Modern aralık yazımı — daha okunaklı, 0.98px hilesi gerekmez */
@media (width >= 900px) { … }
@media (600px <= width < 900px) { … }

Eski yazımda max-width: 899.98px gibi tuhaf değerler görürsün: sebebi min-width: 900px ile max-width: 900px'in tam 900'de ikisinin birden eşleşmesidir. Aralık yazımı bu sorunu ortadan kaldırır.

pointer ve hover özellikleri, "mobil = dokunmatik" varsayımının yanlışlığını çözer: dokunmatik ekranlı dizüstü bilgisayarlar, fare bağlanmış tabletler ve klavyeyle kullanılan telefonlar vardır. Genişlik cihaz türünü söylemez.

/* Doğru soru: "ekran dar mı" değil, "parmakla mı kullanılıyor" */
@media (pointer: coarse) {
  .simge-dugme { min-width: 44px; min-height: 44px; }
}

/* Fare yoksa hover'a bağlı gizli menü kurma */
@media (hover: hover) {
  .kart:hover .eylemler { opacity: 1; }
}

JavaScript tarafında aynı sorgular okunabilir — 12. derste tema anahtarını yazarken işine yarayacak:

const dar = window.matchMedia("(width < 700px)");
dar.addEventListener("change", (e) => { /* e.matches */ });

04Mobil öncelikli yazım

İki yaklaşım vardır:

/* Mobil öncelikli — taban dar ekran, ekledikçe genişliyor */
.kartlar { display: grid; gap: 1rem; }            /* tek sütun */

@media (width >= 600px) { .kartlar { grid-template-columns: repeat(2, 1fr); } }
@media (width >= 960px) { .kartlar { grid-template-columns: repeat(3, 1fr); } }

Mobil öncelikliliğin asıl gerekçesi moda değil, karmaşıklıktır: dar ekran düzeni neredeyse her zaman daha basittir (tek sütun, yığılmış), geniş ekran düzeni ona ekleme yaparak kurulur. Tersini yaptığında her kırılma noktasında bir öncekini geri almak zorunda kalırsın ve kurallar birikir.

Aynı düşünce ilerlemeli geliştirme (progressive enhancement) fikriyle uyumludur: en yalın hâl herkes için çalışır, imkânlar arttıkça üzerine eklenir.

Kırılma noktası nasıl seçilir

Cihaz genişliklerine göre seçilmez. "iPhone 390, iPad 768, dizüstü 1366" listesi her yıl değişir ve hiçbir zaman tam değildir. Doğru ölçüt içeriktir: pencereyi yavaşça daralt ve düzenin bozulduğu ilk noktada kırılma noktası koy.

• Metin satırı 75 karakteri aştı mı → genişliği sınırla (max-width: 70ch).
• Üç sütun sıkıştı mı → ikiye in.
• Yan menü içeriği ezmeye başladı mı → üste al ya da hamburgere çevir.

Sonuçta iki-üç kırılma noktası çoğu projeye yeter. Onlarca kırılma noktası olan bir stil dosyası genelde yanlış araç seçildiğinin işaretidir — o iş muhtemelen clamp() ya da auto-fit ile medya sorgusuz yapılabilirdi.

05Medya sorgusu gerektirmeyen duyarlılık

Modern CSS'in en büyük değişimi budur: esnekliğin çoğu artık kuralın kendisinde.

/* 1. Genişlik: küçük olan kazansın */
.icerik { width: min(100% - 2rem, 70ch); margin-inline: auto; }

/* 2. Akıcı yazı boyutu — taban ve tavanlı */
h1 { font-size: clamp(1.5rem, 1rem + 2.5vw, 3rem); }

/* 3. Kart ızgarası — sütun sayısına tarayıcı karar verir */
.kartlar { display: grid; gap: 1rem;
           grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)); }

/* 4. Sığmazsa alt satıra geç */
.etiketler { display: flex; flex-wrap: wrap; gap: .5rem; }

/* 5. Sabit ama taşmayan kutu */
.kart { width: 800px; max-width: 100%; }

/* 6. Boşluk ekranla birlikte büyüsün, ama bir tabanın altına inmesin */
.bolum { padding-block: max(2rem, 5vh); }

Karar kuralı basittir: ölçüler değişiyorsa (genişlik, boşluk, yazı boyutu, sütun sayısı) medya sorgusuna gerek yoktur. Düzen biçim değiştiriyorsa — yan menü üste taşınıyor, tablo kart görünümüne dönüyor, gezinme hamburgere çevriliyor — medya sorgusu gerekir.

06Esnek görseller ve medya

/* Her projede bulunan iki satır */
img, video, svg { max-width: 100%; height: auto; }

height: auto olmadan, HTML'deki height özniteliği görseli ezer ve oran bozulur. 2. derste öğrendiğin kural hâlâ geçerli: width/height özniteliklerini yaz (yerleşim kayması için), CSS ile de esnet.

<img src="foto-800.jpg"
     srcset="foto-400.jpg 400w, foto-800.jpg 800w, foto-1600.jpg 1600w"
     sizes="(width >= 900px) 50vw, 100vw"
     width="1600" height="900" alt="…">

sizes, tarayıcıya "bu görsel yerleşimde ne kadar yer kaplayacak" der; tarayıcı bunu DPR ile çarpıp srcset'ten uygun dosyayı seçer. sizes yazmazsan tarayıcı 100vw varsayar ve gereğinden büyük dosya indirir. Bu, mobil kullanıcının veri paketini boşa harcayan en yaygın hatalardan biridir.

/* Kırpma: kutuya sığdır ama oranı bozma */
.kapak img { width: 100%; aspect-ratio: 16 / 9; object-fit: cover; object-position: center; }

/* contain: tamamı görünsün, boşluk kalsın (logo için) */
.logo img { aspect-ratio: 1; object-fit: contain; }

object-fit: cover, farklı oranlarda gelen kullanıcı görsellerini tek tip kartlarda göstermenin standart yoludur. object-position ile kırpma odağını kaydırabilirsin — portrelerde top genelde daha iyi sonuç verir.

Yazı tipleri de duyarlılığın parçasıdır: web yazı tipi inene kadar metnin görünmez kalması (FOIT) algılanan hızı düşürür ve inince oluşan geçiş yerleşim kaymasına yol açar. font-display: swap ile önce yedek yazı tipi gösterilir; kaymayı azaltmak için yedek yazı tipinin ölçüleri (size-adjust) ayarlanabilir.

07Kapsayıcı sorguları

Medya sorgularının yapısal bir sınırı vardır: görünüm alanını ölçerler, bileşenin bulunduğu yeri değil. Aynı kart bileşeni geniş bir içerik alanında da, dar bir yan sütunda da kullanılabilir; ekran geniş olduğu hâlde kartın yeri dardır ve medya sorgusu bunu göremez.

/* Ebeveyni sorgulanabilir hâle getir */
.kart-yuvasi { container-type: inline-size; container-name: kart; }

/* Artık ölçülen şey EKRAN değil, KAPSAYICI genişliği */
@container kart (width >= 400px) {
  .kart { display: grid; grid-template-columns: 120px 1fr; gap: 1rem; }
}

Bu, bileşen tabanlı geliştirmenin (10. ve 11. hat) eksik parçasıydı: bir bileşen artık nerede kullanıldığını bilmeden kendi düzenine karar verebiliyor. Bilinmesi gereken sınırlar: kapsayıcı ögesinin kendisi kendi sorgusuna göre stillenemez (bu yüzden bir sarmalayıcı gerekir) ve container-type: inline-size ögeye bir boyut sınırlaması getirir. Ayrıca cqw/cqi gibi kapsayıcı birimleri de vardır.

08Tuzaklar ve test

Yatay taşmayı bulmanın hızlı yolu konsolda tek satırdır:

document.querySelectorAll("*").forEach(e => {
  if (e.getBoundingClientRect().right > document.documentElement.clientWidth) console.log(e);
});

Test disiplini: DevTools cihaz emülasyonu boyutu ve DPR'yi taklit eder; taklit etmediği şeyler vardır — gerçek dokunma davranışı, yazılım klavyesinin açılınca görünüm alanını kısaltması, mobil tarayıcının adres çubuğu davranışı, ağ ve CPU farkı, iOS Safari'nin kendine özgü davranışları. Kritik ekranlar en az bir gerçek cihazda denenir. Ek olarak dört testi alışkanlık hâline getir: (1) pencereyi 320 px'e kadar daralt, (2) %200 yakınlaştır, (3) yalnız klavyeyle gez, (4) yazdırma önizlemesini aç.

09Mini alıştırma — Bir sayfayı 320 px'e kadar daralt

10Kendini sına

Mobile-first yaklaşımı nedir, neden tercih edilir?

Taban stilleri dar ekran için yazıp, ekran genişledikçe min-width medya sorgularıyla ekleme yapmaktır. Tersi (masaüstü öncelikli) geniş ekranı taban alır ve max-width sorgularıyla küçük ekranda kuralları geri alır. Tercih edilmesinin asıl gerekçesi karmaşıklıktır: dar ekran düzeni neredeyse her zaman daha basittir (tek sütun, yığılmış içerik), karmaşık düzen ona eklenerek kurulur — böylece her kırılma noktasında bir öncekini iptal eden kurallar birikmez ve stil dosyası küçük kalır. İkinci gerekçe, zayıf cihazların en yalın stili almasıdır. Üçüncüsü, mobil kullanımın çoğu kamu hizmetinde masaüstünü geçmiş olmasıdır — varsayılan durumun mobil olması doğal karşılıktır. Ön koşul, <meta name="viewport" content="width=device-width, initial-scale=1"> satırıdır; o olmadan mobil tarayıcı sayfayı 980 px varsayar ve hiçbir medya sorgusu beklendiği gibi çalışmaz. Son olarak bugün mobile-first'ün önemli bir kısmı medya sorgusu bile gerektirmez: clamp(), minmax(), auto-fit ve flex-wrap zaten esnektir.

Kırılma noktalarını (breakpoint) neye göre seçersin?

Cihaz genişliklerine göre değil, içeriğe göre. "iPhone 390, iPad 768, dizüstü 1366" listesi her yıl değişir, hiçbir zaman tam değildir ve aynı genişlikte bambaşka cihazlar bulunur. Doğru yöntem: pencereyi yavaşça daralt ve düzenin bozulduğu ilk noktaya kırılma noktası koy — metin satırı 75 karakteri aştığında genişliği sınırla, üç sütun sıkıştığında ikiye in, yan menü içeriği ezmeye başladığında üste al. Pratikte iki–üç kırılma noktası çoğu projeye yeter. Onlarca kırılma noktası olan bir stil dosyası genelde yanlış araç seçildiğinin işaretidir: o iş muhtemelen clamp() ya da repeat(auto-fit, minmax(...)) ile hiç medya sorgusu olmadan yapılabilirdi. Kural olarak: ölçüler değişiyorsa (boyut, boşluk, sütun sayısı) medya sorgusu gerekmez; düzen biçim değiştiriyorsa (menü hamburgere dönüyor, tablo kart olacak, yan sütun üste taşınacak) gerekir. Bir de genişliğin cihaz türünü söylemediğini unutma: dokunma hedefi kararı için pointer: coarse, :hover'a bağlı arayüz için hover: hover sorulur.

Görselleri duyarlı yapmanın yolları nelerdir? srcset ile sizes ne işe yarar?

Temel satır img { max-width: 100%; height: auto; } — görsel kabına sığar ve oranı korunur (height: auto olmadan HTML'deki height özniteliği oranı bozar). Bu, dosyanın boyutunu küçültmez; onun için srcset gerekir: aynı görselin farklı çözünürlüklerini genişlikleriyle listelersin (foto-800.jpg 800w) ve tarayıcı, cihazın piksel oranını da hesaba katarak uygun olanı seçer. sizes ise tarayıcıya görselin yerleşimde ne kadar yer kaplayacağını söyler ((width >= 900px) 50vw, 100vw); yazılmazsa tarayıcı 100vw varsayar ve gereğinden büyük dosya indirir — mobil veri paketini boşa harcayan yaygın bir hatadır. Biçim ya da kırpma değişecekse <picture> + <source> kullanılır (AVIF/WebP sunumu ya da mobilde farklı bir kadraj). Kutuya sığdırırken oranı korumak için aspect-ratio + object-fit: cover, odak için object-position kullanılır. Ve performans/kayma tarafı: width/height özniteliklerini yaz (CLS), ekran dışı görsellere loading="lazy" ver ama ilk ekrandaki hero görseline verme.

Kapsayıcı sorguları (@container) neden gerekti? Medya sorgusundan farkı nedir?

Medya sorguları görünüm alanını ölçer; bileşenin bulunduğu yeri değil. Bileşen tabanlı geliştirmede aynı kart geniş bir içerik alanında da, dar bir yan sütunda da, bir kalıcı pencerede de kullanılır — ekran geniş olduğu hâlde kartın yeri dar olabilir ve medya sorgusu bunu göremez. Sonuç: bileşen, kullanıldığı yeri bilmeden doğru düzeni seçemez ve yerleşime özel sınıflar (kart--dar) yazmak zorunda kalırsın. @container bunu çözer: ebeveyne container-type: inline-size verilir, sorgu artık kapsayıcının genişliğini ölçer ve bileşen kendi düzenine kendi karar verir. Bilinmesi gereken sınırlar: bir öge kendi kapsayıcı sorgusuna göre stillenemez (bu yüzden bir sarmalayıcı gerekir), container-type ögeye boyut sınırlaması getirir, ve cqw/cqi gibi kapsayıcı birimleri ayrıca vardır. Medya sorguları ortadan kalkmaz: sayfa iskeleti, yazdırma, koyu tema ve pointer/hover gibi cihaz düzeyindeki sorular hâlâ onların işidir.

11Sınav köşesi