HTML5 ve CSS3 ile Modern Web Tasarım: Güncel Uygulama Örnekleri

HTML5 ve CSS3 ile modern web tasarım, bugün tarayıcıların yerleşik olarak sunduğu yetenekleri kullanarak daha az kodla daha sağlam arayüzler kurmak anlamına geliyor. 2012'den beri müşteri projelerinde ön yüz koduyla uğraşıyorum ve son birkaç yılda CSS'in eskiden JavaScript gerektiren pek çok işi tek başına çözdüğünü görüyorum. Bu yazıda semantik HTML, Grid, Flexbox, container queries, custom properties ve :has() seçicisini gerçek kullanım örnekleriyle anlatıyorum.

Amacım bir yazılım eğitimi sunmak değil. Daha çok, kurumsal bir web sitesinin ön yüzünde hangi tekniğin neden tercih edildiğini, hangi hatanın bütçeyi ve performansı nasıl etkilediğini sahadan aktarmak istiyorum. Tasarım sürecinin genel çerçevesini merak ediyorsanız web tasarım hizmeti sayfasında nasıl çalıştığımı özetledim.

HTML5 ve CSS3 ile modern web tasarım ne demektir?

HTML5 ve CSS3 ile modern web tasarım, içeriği anlamlı HTML etiketleriyle işaretleyip düzeni, rengi ve etkileşimi güncel CSS özellikleriyle kuran bir yaklaşımdır. Grid ve Flexbox düzeni, container queries bileşen bazlı esnekliği, custom properties ise tutarlı bir tasarım sistemini sağlar. Sonuç olarak daha hafif, erişilebilir ve bakımı kolay sayfalar elde edersiniz.

Eski yöntemde düzen için float, tablo hileleri ya da ağır CSS çerçeveleri kullanırdık. Bugün ise tarayıcı bu işlerin çoğunu doğrudan üstleniyor. Dolayısıyla modern tasarım, yeni bir estetik akımdan çok, platformun kendi araçlarına güvenmek demek.

Bu yaklaşımın işletme tarafında somut karşılıkları var. Daha az kod, daha az hata ve daha hızlı yükleme demek. Ayrıca bir sonraki geliştirici projeyi devraldığında standart yapıları kolayca okuyabiliyor. Bu nedenle ben teklif hazırlarken bile kullanılacak teknik yaklaşımı açıkça yazıyorum.

HTML5 ve CSS3 terimleri bugün hâlâ doğru mu?

Kısa cevap: pazarlama dilinde doğru, teknik dilde eksik. HTML artık numaralı sürümlerle ilerlemiyor. Standardı WHATWG topluluğu HTML Living Standard adıyla sürekli güncelliyor ve W3C ile yapılan anlaşmadan sonra tek geçerli sürüm bu yaşayan metin oldu. Yani "HTML5" dediğimiz şey aslında sürekli gelişen güncel HTML.

CSS tarafında durum benzer. CSS3 tek bir belge değil; Grid, Flexbox, renkler, seçiciler gibi ayrı modüllerden oluşan bir aile. Her modül kendi hızında olgunlaşıyor. Bu yüzden "CSS4" diye bir sürüm de beklemeyin.

Peki bu ayrım size ne kazandırır? Bir ajans ya da geliştiriciyle konuşurken "sitemiz HTML5 ve CSS3 ile yapılacak" cümlesi tek başına bir kalite garantisi değildir, çünkü neredeyse her site bu tanıma girer. Asıl sormanız gereken, hangi modern özelliklerin kullanılacağı ve eski tarayıcılar için nasıl bir yedek plan kurulacağıdır.

Semantik HTML neden hâlâ her şeyin temelidir?

Semantik HTML, içeriğin ne olduğunu etiketin kendisiyle anlatmak demek. Bir navigasyon menüsünü düz bir div yerine nav etiketiyle, ana içeriği main ile, bağımsız bir yazıyı article ile işaretlediğinizde tarayıcı, ekran okuyucu ve arama motoru sayfanın yapısını doğrudan anlar.

Sahada en sık gördüğüm sorun, her şeyin div ve span ile kurulduğu sayfalar. Görsel olarak kusursuz görünseler de klavyeyle gezinmek zorlaşıyor, ekran okuyucu kullanıcısı başlık hiyerarşisini bulamıyor. Üstelik bu eksikleri sonradan ARIA öznitelikleriyle yamamaya çalışmak, en baştan doğru etiketi seçmekten çok daha pahalı.

Arama motoru tarafında da semantik yapı işinizi kolaylaştırıyor. Doğru başlık sırası ve anlamlı bölümler, içeriğinizin konusunu netleştirir. Bunun üzerine yapısal veri eklemek isterseniz schema markup rehberi iyi bir sonraki adım olur. Ancak şunu unutmayın: yapısal veri, zayıf bir HTML iskeletini telafi etmez.

Hangi semantik etiketleri nerede kullanmalısınız?

Kurumsal sitelerde tekrar tekrar kullandığım temel eşleşmeleri aşağıya çıkardım. Bu liste her projede başlangıç noktam oluyor.

• header: Logo, ana menü ve iletişim butonunu içeren üst alan. Sayfa başına birden fazla olabilir, örneğin bir makalenin kendi başlık alanı.
• nav: Ana menü ve kırıntı navigasyonu gibi önemli bağlantı grupları. Footer'daki her bağlantı listesini nav yapmanıza gerek yok.
• main: Sayfanın benzersiz ana içeriği. Sayfada yalnızca bir tane görünür main olmalı.
• article: Tek başına anlam taşıyan içerik, örneğin blog yazısı, vaka çalışması ya da ürün kartı.
• section: Kendi başlığı olan tematik bölüm. Başlığı yoksa büyük ihtimalle div yeterlidir.
• aside: Ana akışa bağlı ama ondan ayrılabilir içerik, örneğin ilgili yazılar kutusu.
• footer: Telif, iletişim ve yasal bağlantılar.
• button ve a: Bir işlem tetikleniyorsa button, başka bir adrese gidiliyorsa a. Tıklanabilir div kullanmayın.

Son madde özellikle önemli. Tıklanabilir bir div, klavyeyle odaklanamaz ve ekran okuyucuya kendini buton olarak tanıtmaz. Oysa yerel button etiketi bunların hepsini ücretsiz getirir.

Formlarda yerel HTML özellikleri size ne kazandırır?

Formlar, bir kurumsal sitenin para kazandıran noktasıdır; dolayısıyla burada yerel HTML özelliklerini kullanmak doğrudan dönüşüme dokunur. Örneğin type="email" ve type="tel" mobil cihazlarda doğru klavyeyi açar. autocomplete özniteliği ise tarayıcının kayıtlı bilgileri önermesini sağlar ve kullanıcıyı gereksiz yazmaktan kurtarır.

Doğrulama tarafında required, minlength ve pattern öznitelikleri basit kontrolleri JavaScript olmadan çözer. Ancak bunları sunucu tarafı doğrulamanın yerine koymayın; tarayıcı doğrulaması yalnızca kullanıcıya hızlı geri bildirim içindir.

Bir de label meselesi var. Her alanın görünür ve alana bağlı bir label etiketi olmalı. Placeholder metni label yerine geçmez, çünkü kullanıcı yazmaya başladığında kaybolur. Teklif ve randevu formlarının tasarımını form tasarımı yazısında ayrıntılı ele aldım; buradaki teknik temel o yazıdaki önerilerin çoğunu mümkün kılıyor.

Ayrıca modern HTML, eskiden kütüphane gerektiren bazı bileşenleri de yerel olarak sunuyor. Açılır kapanır SSS bölümleri için details ve summary etiketlerini, modal pencereler için dialog etiketini kullanabilirsiniz. Böylece hem kod küçülür hem de klavye davranışı doğru gelir.

Flexbox mı Grid mi: hangisini ne zaman seçmelisiniz?

İkisi rakip değil, tamamlayıcı araçlar. Kabaca şöyle düşünebilirsiniz: Flexbox tek eksende, yani satır ya da sütun boyunca içeriği hizalar; Grid ise satır ve sütunu birlikte yöneten iki boyutlu bir ızgara kurar. Aşağıdaki tablo, projelerde karar verirken kullandığım özet.

Pratikte ikisini iç içe kullanıyorum: sayfa ve kart listesi Grid ile, kartın içindeki başlık, etiket ve buton hizası Flexbox ile. Bu ayrım kodu okunabilir tutuyor ve her aracın güçlü olduğu yerde çalışmasını sağlıyor.

CSS Grid ile sayfa iskeletini nasıl kurarsınız?

Grid'in en sevdiğim tarafı, medya sorgusu yazmadan duyarlı kart listeleri kurabilmesi. Örneğin bir hizmet listesi için kapsayıcıya display: grid; gap: 1.5rem; grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr)); yazmanız yeterli. Tarayıcı, ekran genişliğine göre sığabilecek kadar sütun açar ve her kartın en az 16rem genişlikte kalmasını sağlar.

Sayfa iskeleti için ise grid-template-areas çok okunaklı bir yol sunuyor. Başlık, kenar çubuğu, içerik ve footer alanlarına isim verip bunları bir harita gibi yerleştiriyorsunuz. Mobilde tek sütun, masaüstünde iki sütun istediğinizde yalnızca bu haritayı değiştirmeniz yetiyor; HTML sırası aynı kalıyor.

Burada önemli bir uyarım var. Grid ile görsel sırayı HTML sırasından tamamen koparmayın. Ekran okuyucu ve klavye kullanıcısı HTML sırasını izler; görsel sıra ile odak sırası çelişirse kafa karışıklığı yaratırsınız. Bu nedenle önce içeriği mantıklı bir sırayla yazın, ardından düzeni Grid ile şekillendirin.

Son olarak subgrid özelliğinden bahsetmek istiyorum. Yan yana kartlarda başlıklar farklı uzunlukta olduğunda butonlar aynı hizada durmaz. Subgrid, kartların iç satırlarını üst ızgaraya bağlayarak bu sorunu ekstra JavaScript olmadan çözer ve güncel tarayıcıların hepsinde destekleniyor.

Flexbox hangi bileşenlerde gerçekten parlıyor?

Flexbox, içeriğin boyutunun belirleyici olduğu küçük bileşenlerde rakipsiz. Ana menü bunun en iyi örneği: bağlantıları yan yana dizer, aralarına eşit boşluk koyar ve logoyu sola, iletişim butonunu sağa itersiniz. Bunun için display: flex; align-items: center; gap: 1rem; ve butona margin-left: auto yazmak çoğu zaman yeterli.

Kart içlerinde de sık kullanıyorum. Kartı dikey bir flex kapsayıcı yapıp açıklama paragrafına flex: 1 verdiğinizde, buton her zaman kartın dibine yapışır. Böylece farklı uzunluktaki metinler düzeni bozmaz.

Etiket bulutları ve filtre çipleri gibi sarması gereken gruplarda ise flex-wrap: wrap hayat kurtarır. Öğeler sığmadığında bir alt satıra geçer ve medya sorgusu yazmanıza gerek kalmaz.

Öte yandan Flexbox'ı iki boyutlu kart listeleri için zorlamayın. Son satırdaki kartların genişlemesi ya da hizasının kayması gibi sorunlar genellikle yanlış araç seçiminden kaynaklanır. Bu tür durumlarda Grid'e geçmek hem kodu hem de kafanızı rahatlatır.

Container queries medya sorgularından neden farklıdır?

Medya sorgusu ekranın genişliğine bakar; container query ise bileşenin içinde bulunduğu kapsayıcının genişliğine. Bu küçük fark, bileşen tabanlı tasarımda büyük bir kapı açıyor. Aynı ürün kartı geniş bir ana alanda yatay, dar bir kenar çubuğunda dikey görünebilir ve bunun için ekran boyutunu hiç bilmesi gerekmez.

Kullanımı basit. Önce kapsayıcıya container-type: inline-size tanımlıyorsunuz. Ardından @container (min-width: 30rem) bloğu içinde kartın geniş hâlini yazıyorsunuz. Böylece kart, nereye yerleştirilirse yerleştirilsin kendi alanına göre uyum sağlıyor. MDN container queries belgesi tüm sözdizimini örnekleriyle gösteriyor.

Container query birimleri de işe yarıyor. Örneğin cqi birimi, kapsayıcının satır yönündeki genişliğinin yüzdesini ifade eder. Kart başlığının yazı boyutunu bu birimle ayarladığınızda, başlık kartın boyutuna göre ölçeklenir.

Peki medya sorguları tamamen gidiyor mu? Hayır. Sayfanın genel iskeleti, menünün mobil hâle geçmesi gibi ekran düzeyindeki kararlar için medya sorgusu hâlâ doğru araç. Ben kuralı şöyle koyuyorum: sayfa düzeni medya sorgusuyla, tekrar kullanılan bileşenler container query ile. Mobil öncelikli düşünmenin genel mantığını mobil öncelikli tasarım yazısında anlattım.

Custom properties ile tasarım sistemini nasıl kurarsınız?

Custom properties, yani CSS değişkenleri, renk, boşluk ve yazı boyutu gibi kararları tek bir yerde tanımlayıp tüm sitede kullanmanızı sağlar. Örneğin kök öğede --renk-ana: #0b5fff; tanımlayıp butonlarda background: var(--renk-ana); yazarsınız. Marka rengi değiştiğinde tek satırı güncellemeniz yeterli olur.

Sass değişkenlerinden farkı şu: CSS değişkenleri tarayıcıda yaşar. Yani çalışma anında değişebilir, bir bölüm içinde yeniden tanımlanabilir ve JavaScript ile okunabilir. Örneğin koyu bir kampanya bandının içinde metin rengi değişkenini yeniden atadığınızda, o bandın içindeki tüm bileşenler otomatik olarak uyum sağlar.

Ben tasarım sistemini genellikle üç katmanda kuruyorum:

1. Ham değerler: Paletteki tüm renkler, boşluk ölçeği ve yazı boyutu ölçeği.
2. Anlamsal değerler: Ana renk, yüzey rengi, metin rengi, hata rengi gibi görev adları. Bileşenler yalnızca bunları kullanır.
3. Bileşen değerleri: Butonun iç boşluğu ya da kartın köşe yuvarlaklığı gibi yerel ayarlar.

Bu katmanlama, tasarım aracındaki kararların koda birebir taşınmasını kolaylaştırıyor. Figma tarafındaki değişkenleri ve bileşen yapısını nasıl kurduğumu Figma ile arayüz tasarımı yazısında bulabilirsiniz. Renk kodlarını hızlıca dönüştürmek içinse HTML renk kodları aracını kullanabilirsiniz.

:has() seçicisi CSS'te neyi değiştirdi?

:has() uzun yıllar "ebeveyn seçicisi" olarak beklenen bir özellikti. Bir öğeyi, içinde ne bulunduğuna göre biçimlendirmenizi sağlar. Örneğin .kart:has(img) yalnızca görseli olan kartları seçer. Böylece görselli ve görselsiz kartlar için ayrı sınıf eklemek zorunda kalmazsınız.

Formlarda kullanımı özellikle pratik. .alan:has(input:invalid) ile hatalı girişi olan alanın tüm kapsayıcısını kırmızı çerçeveyle vurgulayabilirsiniz. Ayrıca form:has(input[type=checkbox]:checked) gibi bir kural, onay kutusu işaretlendiğinde gönder butonunu görünür hâle getirebilir. Eskiden bu davranışlar için JavaScript yazardık.

Sayfa düzeyinde de işe yarıyor. Örneğin mobil menü açıkken arka plandaki sayfanın kaymasını engellemek için body öğesine, içinde açık menü bulunduğunda farklı bir stil verebilirsiniz. MDN :has() sayfası güncel tarayıcı desteğini ve sınırlamaları listeliyor.

Yine de bir uyarım var: :has() güçlü olduğu için onu her yerde kullanmak cazip geliyor. Ancak çok geniş kapsamlı ve iç içe :has() kuralları, büyük sayfalarda stil hesaplamasını ağırlaştırabilir. Bu yüzden seçicileri mümkün olduğunca dar bir bileşene bağlamanızı öneririm.

Modern CSS ile karanlık mod ve renk yönetimi nasıl kurulur?

Kullanıcının işletim sistemi tercihini prefers-color-scheme medya özelliğiyle okuyabilirsiniz. Custom properties ile kurduğunuz anlamsal renkleri bu sorgu içinde yeniden tanımladığınızda, tüm site tek blokla karanlık moda geçer. İşte değişken katmanlamasının asıl faydası burada ortaya çıkıyor.

Ayrıca kök öğeye color-scheme: light dark yazmanızı öneririm. Bu tek satır, form alanları ve kaydırma çubukları gibi tarayıcının kendi çizdiği öğelerin de temaya uymasını sağlar. Aksi halde karanlık sayfanın ortasında beyaz bir giriş kutusu kalabilir.

Renk tarafında daha yeni araçlar da var. color-mix() fonksiyonu, iki rengi belirli oranda karıştırarak hover ve pasif durumlar için ton üretmenizi sağlar. Böylece paleti her durum için ayrı ayrı elle tanımlamak zorunda kalmazsınız.

Bununla birlikte kontrastı her zaman ölçün. Karanlık modda gri metin, koyu yüzey üzerinde kolayca okunaksız hâle gelir. Her tema için metin ve arka plan kontrastını ayrı ayrı kontrol etmek, sonradan gelecek erişilebilirlik şikâyetlerini baştan önler.

Akıcı tipografi ve boşluk için clamp() nasıl kullanılır?

clamp() fonksiyonu bir değere alt sınır, tercih edilen değer ve üst sınır verir. Örneğin başlık için font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem); yazdığınızda başlık küçük ekranda 1.75rem'in altına inmez, büyük ekranda 3rem'i geçmez, arada ise ekranla birlikte akıcı biçimde büyür.

Bu yaklaşım, her kırılım noktası için ayrı yazı boyutu tanımlama zahmetini ortadan kaldırıyor. Aynı mantığı bölüm boşluklarına da uyguluyorum. Mobilde sıkışık, masaüstünde ferah görünen sayfalar, tek bir clamp() tanımıyla doğal olarak oluşuyor.

Burada dikkat etmeniz gereken nokta, tercih edilen değerde mutlaka rem gibi göreli bir birim bulundurmak. Yalnızca vw kullanırsanız, kullanıcı tarayıcıda yazıyı büyüttüğünde başlık tepki vermez ve bu durum erişilebilirliği bozar.

Okunabilirlik için satır uzunluğunu da sınırlayın. Paragraf kapsayıcısına max-inline-size: 65ch gibi bir değer vermek, uzun satırların göz yormasını engeller. Metnin okunabilirliğini ayrıca ölçmek isterseniz okunabilirlik analizi aracı işinize yarayabilir.

Yeni CSS özelliklerini eski tarayıcılarda nasıl güvenle kullanırsınız?

İlk kontrol noktam her zaman Baseline oluyor. web.dev Baseline girişimi, bir özelliğin ana tarayıcıların güncel sürümlerinin hepsinde desteklenip desteklenmediğini tek bakışta gösteriyor. Grid, Flexbox, container queries ve :has() bu listede artık yaygın destekli özellikler arasında yer alıyor.

Yine de kitlenizde eski cihaz kullanan bir kesim varsa katmanlı bir strateji kurmalısınız. Yöntem şu: önce her tarayıcıda çalışan sade bir düzen yazın, ardından gelişmiş davranışı @supports bloğunun içine koyun. Özelliği desteklemeyen tarayıcı bloğu atlar ve sade düzeni gösterir; destekleyen ise zengin sürümü alır.

Örneğin container query ile kart düzeni kuruyorsanız, varsayılan olarak tek sütunlu dikey kart yazın. Geniş düzeni ise @supports (container-type: inline-size) içine taşıyın. Böylece kimse bozuk bir sayfa görmez, yalnızca bazı kullanıcılar daha sade bir sürümle karşılaşır.

Karar verirken Analytics'teki tarayıcı dağılımına bakın. Ziyaretçilerinizin neredeyse tamamı güncel tarayıcı kullanıyorsa, yedek plan için saatlerce emek harcamak gereksiz olabilir. Kısacası destek stratejisi, varsayıma değil kendi verinize dayanmalı.

Modern HTML ve CSS erişilebilirliği nasıl etkiler?

Doğru kullanıldığında olumlu, yanlış kullanıldığında olumsuz. Yerel etiketler ve modern CSS, erişilebilirliğin önemli bir kısmını kendiliğinden getirir; ancak birkaç noktayı bilinçli olarak yönetmeniz gerekir. Projelerde kontrol ettiğim başlıklar şunlar:

• Odak görünürlüğü: :focus-visible ile klavye kullanıcısına belirgin bir odak halkası gösterin, fare kullanıcısını ise rahatsız etmeyin.
• Hareket tercihi: prefers-reduced-motion sorgusuyla, hareket hassasiyeti olan kullanıcılar için animasyonları sadeleştirin.
• Görsel sıra: Grid ve Flexbox ile görsel sırayı değiştirirken odak sırasının mantıklı kaldığını klavyeyle test edin.
• Gizli içerik: display: none ile gizlenen içerik ekran okuyucuya da gizlenir. Yalnızca görsel olarak gizlemek istiyorsanız farklı bir teknik kullanın.
• Kontrast: Her tema ve her durum (hover, pasif, hata) için metin kontrastını ölçün.

Bu kontroller uzun bir denetim gerektirmiyor. Yalnızca fareyi kenara bırakıp sayfayı baştan sona klavyeyle gezmek bile sorunların çoğunu ortaya çıkarıyor. Ben her yayından önce bu beş dakikalık testi mutlaka uyguluyorum.

HTML5 ve CSS3 sayfa hızına ve SEO'ya nasıl katkı sağlar?

Modern CSS'in en az konuşulan faydası, JavaScript ihtiyacını azaltması. Eskiden akordeon, sekme, modal, form vurgulama ve duyarlı kart düzeni için ayrı kütüphaneler yüklerdik. Bugün bunların çoğunu HTML ve CSS ile çözebiliyorsunuz. Daha az JavaScript, tarayıcının ana iş parçacığında daha az yük demek; bu da özellikle etkileşim hızına olumlu yansıyor.

Ayrıca ağır CSS çerçevelerinden vazgeçmek, kullanılmayan stil kodunu ciddi ölçüde azaltabiliyor. Her sayfada yalnızca ihtiyacınız olan kuralları göndermek, ilk görüntünün daha çabuk çizilmesine yardım ediyor. Hızın arama görünürlüğüne etkisini site hızı ve SEO yazısında, ölçüm adımlarını ise Lighthouse performans testi rehberinde anlattım.

Bir de düzen kaymaları var. Görsellere width ve height değerleri vermek ya da aspect-ratio özelliğini kullanmak, görsel yüklenirken sayfanın zıplamasını önler. Bu küçük detay hem kullanıcı deneyimini hem de ölçüm puanlarını iyileştirir.

SEO açısından ise semantik yapı, başlık hiyerarşisi ve temiz kod, arama motorunun sayfanızı doğru yorumlamasına yardım eder. Teknik tarafın diğer başlıklarını teknik SEO ipuçları yazısında topladım.

CSS nesting ve @layer kodunuzu nasıl düzenler?

Yerel CSS nesting, yani iç içe yazım, uzun süre yalnızca Sass gibi ön işlemcilerle mümkündü. Artık güncel tarayıcılar bunu doğrudan destekliyor. Örneğin kart bileşeninin başlık, görsel ve hover kurallarını tek bir blok içinde toplayabilirsiniz. Böylece ilgili kurallar dosyanın farklı köşelerine dağılmaz.

@layer ise özgüllük savaşlarını bitirmek için tasarlanmış bir araç. Sıfırlama stillerini, temel stilleri, bileşenleri ve yardımcı sınıfları ayrı katmanlara koyarsınız. Sonraki katman, seçici ne kadar zayıf olursa olsun öncekini ezer. Dolayısıyla üçüncü taraf bir kütüphanenin stilleri sizin bileşenlerinizi bozamaz.

Yine de iç içe yazımı abartmayın. Üç seviyeden derin yuvalama, okunması zor ve fazla özgül seçiciler üretir. Ben genellikle bir seviyede kalıyor, yalnızca durum ve alt öğe kuralları için ikinci seviyeye iniyorum.

Modern CSS'te en sık yapılan hatalar nelerdir?

Yeni özellikler heyecan verici olduğu için bazı hatalar tekrar tekrar karşıma çıkıyor. En yaygın olanları şöyle sıralayabilirim:

• Her şeyi Grid ile çözmeye çalışmak ve basit bir buton grubunu bile ızgaraya sokmak.
• Custom properties'i anlamsal katman olmadan, rastgele isimlerle tanımlamak. Sonuçta hangi değişkenin nerede kullanıldığı bilinmez hâle gelir.
• Container query tanımlayıp kapsayıcıya container-type vermeyi unutmak. Bu durumda kurallar hiç çalışmaz.
• Animasyonları width, height ya da top gibi düzeni tetikleyen özelliklerle yapmak. Bunun yerine transform ve opacity kullanın.
• !important ile özgüllük sorunlarını bastırmak. Bunun yerine @layer ile stil katmanlarını düzenlemek çok daha sürdürülebilir.

Bu hataların ortak noktası, kısa vadede işi çözüp uzun vadede bakım maliyetini artırması. Özellikle büyük ve çok ekipli projelerde bu maliyet hızla büyüyor. Büyük kurumsal yapılarda ön yüzün nasıl bölündüğünü merak ediyorsanız micro frontend yazısına bakabilirsiniz.

Bir projeye başlarken hangi kontrol listesini uygulamalısınız?

Yeni bir kurumsal site projesine başlarken ön yüz tarafında şu sırayla ilerliyorum. Bu liste, sonradan geri dönüp düzeltme ihtiyacını büyük ölçüde azaltıyor.

1. İçeriği tasarımdan önce semantik HTML olarak yazın ve başlık sırasını kontrol edin.
2. Renk, boşluk ve yazı ölçeğini custom properties ile üç katmanda tanımlayın.
3. Sayfa iskeletini Grid, bileşen içlerini Flexbox ile kurun.
4. Tekrar kullanılan bileşenleri container query ile kendi alanına duyarlı hâle getirin.
5. Tipografi ve bölüm boşluklarını clamp() ile akıcı yapın.
6. JavaScript yazmadan önce details, dialog ve :has() ile çözülüp çözülmediğine bakın.
7. Kitle verinize göre @supports ile yedek düzen gerekip gerekmediğine karar verin.
8. Klavye testi, kontrast ölçümü ve hareket tercihi kontrolünü yapın.
9. Yayından önce hız ve düzen kayması ölçümünü tekrarlayın.

Bu sıralamanın mantığı basit: önce içerik ve anlam, sonra düzen, en son süsleme. Tersinden başladığınızda güzel görünen ama taşınması, çevrilmesi ve bakımı zor bir yapı ortaya çıkıyor.

Sonuç: HTML5 ve CSS3 ile modern tasarıma nereden başlamalısınız?

Özetle modern web tasarım, yeni ve gösterişli efektlerden çok, platformun sunduğu araçları doğru yerde kullanmakla ilgili. Semantik HTML sağlam bir temel kurar; Grid ve Flexbox düzeni sadeleştirir; container queries bileşenleri bağımsız kılar; custom properties ve :has() ise eskiden JavaScript gerektiren işleri CSS'e taşır.

Mevcut bir siteniz varsa her şeyi baştan yazmanız gerekmiyor. Önce en çok ziyaret alan şablonu seçin, div yığınlarını semantik etiketlere çevirin ve renkleri değişkenlere taşıyın. Ardından tek bir bileşeni, örneğin hizmet kartını, container query ile yeniden kurun. Bu küçük adımlar bile bakım kolaylığını hissedilir biçimde artırır.

Yeni bir proje planlıyorsanız ya da mevcut sitenizin ön yüz kalitesini değerlendirmek istiyorsanız, web tasarım sürecimi inceleyip benimle iletişime geçebilirsiniz. Hangi tekniğin sizin projenize gerçekten değer katacağını birlikte netleştirebiliriz.