CSS At-Rule Rehberi: @media, @keyframes ve @layer

CSS dünyasında @ işareti, yüzeyde görünen stil tanımlarının çok daha ötesinde bir anlam taşır.

CSS dünyasında @ Bu yapı, yalnızca bir görsellik tanımlama aracı değil; aynı zamanda tarayıcıya nasıl düşünmesi gerektiğini söyleyen bir komut sistemidir.

Tarayıcının rendering engine katmanında, At-Kuralları CSS'in yorumlanma sürecine dahil olur ve stil uygulanmadan önce izlenecek yolu belirler.

Bu yönüyle At-Kuralları, klasik "Seçici → Özellik → Değer" üçlüsünden ayrılır ve CSS'e karar verme yeteneği kazandırır.

Artık CSS sadece "nasıl görünecek?" sorusunu değil, aynı zamanda "hangi şartlarda uygulanacak?" sorusunu da cevaplar.

At-Kuralları, tek tek elementlere stil vermek yerine, tüm stil sürecini yöneten bir üst kontrol katmanı gibi çalışır.

Bu katman, CSS'in uygulanma sırasını, kapsamını ve hatta hangi kaynakların yükleneceğini belirler.

Örneğin: Artık sadece "buton mavi olsun" demek yerine; "cihaz küçükse farklı stil uygula", "destekleniyorsa bu özelliği aktif et" veya

"önce bu dosyayı yükle" gibi çok daha stratejik kararlar alınabilir.

Bu yaklaşım, CSS'i pasif bir stil dili olmaktan çıkarır ve onu koşul bazlı çalışan dinamik bir sistem haline getirir.

At-Kuralları'nın kapsadığı alan oldukça geniştir. Bu kurallar; yalnızca stil uygulamakla kalmaz, aynı zamanda projenin ihtiyaç duyduğu

harici kaynakları yönetir ve hangi koşullarda hangi stillerin aktif olacağını belirler.

Örneğin: Farklı ekran boyutları, kullanıcı tercihleri ( karanlık mod gibi ), cihaz yetenekleri veya tarayıcı desteği gibi faktörler, At-Kuralları sayesinde kontrol altına alınır.

Bu yüzden At-Kuralları, CSS'in yalnızca görünen kısmı değil; arka planda çalışan karar mekanizması olarak düşünülebilir.

Adeta CSS'in beyni gibi davranarak, hangi stilin ne zaman ve nasıl uygulanacağını yönetir.

Tarayıcı, CSS dosyasını işlerken At-Kuralları'nı sıradan stil kuralları gibi ele almaz.

Öncelikle bu kuralları analiz eder ve hangi blokların aktif olacağına karar verir.

Bu süreçte bazı kurallar hemen uygulanırken, bazıları belirli koşullar gerçekleşene kadar bekletilir.

Bu da CSS içinde bir nevi koşullu yürütme mekanizması oluşturur.

Sonuç olarak At-Kuralları; sadece "stil yazmak" değil, aynı zamanda stilin ne zaman, nerede ve hangi şartlarda devreye gireceğini tasarlamak anlamına gelir.

@media kuralı, CSS içinde tanımlanan stillerin her durumda uygulanmasını engelleyerek, yalnızca belirli koşullar sağlandığında devreye giren

koşul tabanlı bir kontrol yapısı sunar.

Bu yapı sayesinde CSS, statik bir stil tanımlama dili olmaktan çıkar ve ortama duyarlı kararlar alabilen bir sistem haline gelir.

Tarayıcı, bir @media bloğunu değerlendirirken önce ortam özelliklerini ( ekran genişliği, çözünürlük, kullanıcı tercihi gibi ) analiz eder; ardından yalnızca koşul doğruysa ilgili stil bloklarını aktif hale getirir.

Bu durum, CSS içerisinde doğrudan bir if mantığı oluşturur: "Eğer şart sağlanıyorsa uygula, değilse yok say".

@media sorguları, modern web geliştirmede kritik bir rol oynayan Responsive Design yaklaşımının merkezinde yer alır.

Farklı cihazların farklı ekran boyutlarına sahip olması, tek bir sabit tasarım anlayışını yetersiz hale getirmiştir.

İşte bu noktada @media, arayüzün her ortamda uyumlu ve okunabilir kalmasını sağlar.

Aynı web sayfası; geniş bir masaüstü ekranda çok sütunlu ve ferah bir yapı sunarken, daha küçük mobil ekranlarda sadeleşerek tek sütunlu, dokunma odaklı bir düzene dönüşebilir.

Bu dönüşüm, manuel olarak farklı sayfalar yazmak yerine, tamamen @media kuralları ile dinamik olarak yönetilir.

@media yalnızca ekran genişliği ile sınırlı değildir. Bu kural, çok daha geniş bir ortam bilgisini değerlendirebilir.

Örneğin: yükseklik, çözünürlük, orientation veya kullanıcı tercihleri gibi faktörler de kontrol edilebilir.

Özellikle "prefers-color-scheme" gibi özellikler sayesinde, kullanıcının sistem tercihlerine göre karanlık mod veya açık mod otomatik olarak uygulanabilir.

Çalışma Mantığı: Filtreleme ve Aktivasyon @media blokları, tarayıcı tarafından bir filtreleme sistemi gibi çalıştırılır.

Önce koşul değerlendirilir; eğer sonuç doğruysa içerideki tüm stil kuralları normal CSS kuralları gibi işlenir.

Eğer koşul sağlanmazsa, bu blok tamamen yok sayılır ve performans açısından herhangi bir yük oluşturmaz.

Bu da geliştiriciye, tek bir CSS dosyası içinde farklı senaryoları güvenli şekilde yönetme imkanı sunar.

@media kuralı, CSS içinde yer alan en güçlü koşullu kontrol yapılarından biridir ve stil kurallarını her durumda uygulamak yerine

ortama göre filtreleyen bir sistem kurar.

Bu yaklaşım sayesinde CSS, tek tip bir görünüm dayatmak yerine; bulunduğu ortamın fiziksel ve teknik özelliklerine göre uyum sağlayan esnek bir yapı haline gelir.

Tarayıcı, @media ifadesini işlerken önce ortam bilgisini analiz eder ( cihaz türü, ekran boyutu, çözünürlük gibi ) ve yalnızca eşleşme sağlanıyorsa ilgili stil bloğunu devreye alır.

Bu yapı, CSS içerisinde görünmeyen ama güçlü bir mantıksal kontrol katmanı oluşturur.

@media kuralı temelde iki parçadan oluşur: medya türü ve medya özellikleri.

Medya türü, stilin hangi ortamda geçerli olacağını belirlerken; medya özellikleri bu ortamın hangi şartlarda geçerli sayılacağını tanımlar.

Bu yapı sayesinde, yalnızca "nerede?" değil, aynı zamanda "hangi şartlarda?" sorusu da cevaplanmış olur.

Örneğin: Bir stil bloğu sadece geniş ekranlarda aktif edilirken, başka bir blok yalnızca düşük çözünürlüklü veya baskı ortamlarında çalışacak şekilde tanımlanabilir.

Bu sayede aynı tasarım, farklı bağlamlarda tamamen farklı davranışlar sergileyebilir.

Screen: Işık yayan tüm dijital ekranları kapsar.

Masaüstü bilgisayarlar, tabletler ve mobil cihazlar bu kategoriye girer ve modern web uygulamalarının büyük çoğunluğu bu ortam için optimize edilir.

Print: İçeriğin fiziksel çıktıya dönüştüğü senaryoları hedefler.

Bu modda amaç görsellikten çok okunabilirlik ve sadelik olduğu için, gereksiz arayüz bileşenleri kaldırılır ve içerik ön plana çıkarılır.

All: Tüm medya türlerini kapsayan varsayılan davranıştır.

Eğer bir medya türü belirtilmezse, stil kuralları otomatik olarak tüm ortamlarda geçerli kabul edilir.

Tek Kaynak, Çoklu Deneyim @media yapısının en büyük avantajı, tek bir stil dosyası üzerinden farklı cihazlara özel deneyimler sunabilmesidir.

Örneğin: Bir navigasyon menüsü, mobil cihazlarda dar alanı verimli kullanmak için gizlenip açılır hale gelirken, masaüstünde geniş bir yatay menü olarak gösterilebilir.

Bu yaklaşım, farklı platformlar için ayrı ayrı tasarım üretmek yerine, tek bir sistem üzerinden çoklu deneyim üretme imkanı sağlar.

Sonuç olarak @media, sadece bir stil kuralı değil; modern web arayüzlerinin adaptasyon yeteneğini sağlayan stratejik bir yapı taşıdır.

Orta seviye @media kullanımı, yalnızca ekran boyutlarına tepki vermek değil; tasarımın nerede kırılması gerektiğini bilinçli şekilde planlamak anlamına gelir.

Bu yaklaşımda amaç, stil kurallarını rastgele değil; tam olarak ihtiyaç duyulduğu anda devreye girecek şekilde zamanlamaktır.

Tarayıcı açısından bakıldığında bu, gereksiz stil hesaplamalarını azaltır ve yalnızca aktif olan senaryoların render sürecine dahil edilmesini sağlar.

Breakpoint, bir arayüzün mevcut düzeninin artık verimli çalışmadığı ve yeni bir yerleşime ihtiyaç duyduğu kritik geçiş anıdır.

Bu noktalar sabit cihazlara göre değil, içeriğin davranışına göre belirlenmelidir.

Örneğin: Bir kart yapısı sıkışmaya başladığında veya metin okunamaz hale geldiğinde, bu durum bir breakpoint ihtiyacını işaret eder.

Bu nedenle modern yaklaşım, "tablet = 768px" gibi ezbere değerlerden ziyade, içeriğe duyarlı breakpoint tasarımı önerir.

Doktrin 1: Mobil Öncelikli (min-width) - Modern Yaklaşım Mobil öncelikli yaklaşımda, temel stil en küçük ekranlar için yazılır ve daha büyük ekranlar için min-width kullanılarak kademeli olarak genişletilir.

Bu model, aşamalı geliştirme prensibine dayanır.

Küçük cihazlar sadece gerekli minimum stili yüklerken, daha güçlü cihazlar ekstra özellikleri alır.

Bu da performans açısından daha optimize ve sürdürülebilir bir yapı sağlar.

Doktrin 2: Masaüstü Öncelikli (max-width) - Azalan Kullanım Masaüstü öncelikli yaklaşımda, büyük ekranlar için yazılan stil daha sonra max-width ile küçültülmeye çalışılır.

Bu yöntem, küçük cihazların gereksiz yere fazla stil yüklemesine ve sonrasında bu stillerin override edilmesine neden olur.

Bu da hem performans hem de bakım açısından dezavantaj oluşturur.

Aralık Tanımlama (Range Thinking) Modern medya sorgularında önemli bir diğer yaklaşım, tek bir eşik yerine belirli bir aralığı hedeflemektir.

Bu sayede yalnızca tek bir cihaz değil, benzer davranış gösteren cihaz grupları kontrol altına alınabilir.

Örneğin: Bir tasarım, belirli bir genişlik aralığında farklı bir layout kullanacak şekilde planlanabilir.

And (Koşul Zinciri): Birden fazla koşulu birleştirerek daha hassas hedefleme yapılmasını sağlar.

Bu operatör ile, birden fazla şartın aynı anda sağlanması zorunlu hale getirilir.

Örneğin: Belirli bir genişlik aralığı ve yön (orientation) birlikte kontrol edilerek çok daha spesifik senaryolar oluşturulabilir.

Not (Negatif Mantık): Belirli bir koşulun dışındaki tüm durumları hedefler.

Bu operatör, özellikle istisna durumları tanımlamak için kullanışlıdır.

Only (Uyumluluk Katmanı): Modern CSS'te nadiren ihtiyaç duyulan, daha çok eski tarayıcı davranışlarını kontrol etmek için kullanılan bir yapıdır.

Günümüzde çoğu modern tarayıcı medya sorgularını doğru yorumladığı için, bu operatörün kullanım alanı oldukça sınırlıdır.

İleri seviyede @media kullanımı, belirli cihazları hedeflemekten ziyade, içeriğin davranışını analiz etmeye dayanır.

Cihaz isimlerine veya sabit piksel değerlerine bağlı kalmak, zamanla kırılgan ve sürdürülemez bir yapı oluşturur.

Bunun yerine modern yaklaşım, "içerik ne zaman bozuluyor?" sorusunu merkeze alır ve breakpoint'leri bu davranışa göre belirler.

Bu bakış açısı, duyarlı tasarımı cihaz bağımlı bir çözüm olmaktan çıkarır ve evrensel, adaptif bir sistem haline getirir.

Modern medya sorguları, yalnızca ekran boyutlarını değil; kullanıcının tercihlerini ve cihazın çalışma koşullarını da dikkate alır.

Bu durum, CSS'i yalnızca bir stil dili olmaktan çıkarıp, kullanıcı deneyimi mühendisliği aracına dönüştürür.

Örneğin: prefers-color-scheme özelliği, kullanıcının sistem genelinde seçtiği tema tercihini algılayarak arayüzü otomatik olarak uyumlu hale getirir.

prefers-reduced-motion ise animasyon yoğunluğunu azaltarak, hem performansı artırır hem de hassas kullanıcılar için daha konforlu bir deneyim sunar.

Benzer şekilde, orientation ve resolution gibi özellikler, arayüzün fiziksel ve görsel bağlama göre optimize edilmesini sağlar.

Bu sayede aynı tasarım, farklı kullanıcı ihtiyaçlarına göre davranış değiştirebilen akıllı bir sistem haline gelir.

Tarayıcı, bir sayfayı işlerken belirli bir pipeline ( işlem hattı ) izler: stil hesaplama ( style ), yerleşim ( layout ) ve boyama ( paint ).

@media sorguları, bu sürecin en başında devreye girerek hangi stil bloklarının aktif olacağını belirler.

Bu sayede gereksiz stil kuralları, hesaplama sürecine dahil edilmeden elenir.

Mühendislik Detayı: Performans ve Optimizasyon Önemli bir teknik detay: @media sorguları CSS dosyasının indirilmesini engellemez.

Ancak koşul sağlanmadığı sürece ilgili stil blokları aktif hale getirilmez ve layout hesaplamalarına dahil edilmez.

Bu durum, özellikle karmaşık arayüzlerde reflow ve repaint maliyetlerini azaltır.

Doğru yapılandırılmış bir medya sorgusu stratejisi, tarayıcının daha az hesaplama yapmasını sağlar ve sayfanın etkileşime girme süresini

doğrudan iyileştirir.

Özellikle mobil öncelikli yaklaşım ile birlikte, gereksiz stil yükünün küçük cihazlarda işlenmemesi, performans açısından kritik bir avantaj sağlar.

@container kuralı, web tasarımının on yılı aşkın süredir dayandığı "ekran boyutuna bağımlılık" paradigmasını kökünden değiştirerek; bir öğenin stillerini global görüntü alanının ( viewport ) anlık genişliğine göre değil, doğrudan içinde barındığı en yakın ebeveyn konteynerinin fiziksel boyutlarına göre değiştirmeyi sağlayan devrim niteliğinde bir At-Kuralıdır.

Bu mekanizma, öğelerin "Dünya ne kadar büyük?" ( Ekran boyutu ) sorusunu sormayı bırakıp, "Evim ne kadar geniş?" ( Kapsayıcı boyutu ) sorusuna odaklanmasını sağlayarak, CSS'e gerçek anlamda bir bağlam farkındalığı (context-awareness) kazandırır.

Bu özellik, duyarlı tasarımı klasik "sayfa seviyesi" ( Macro Layout ) yönetiminden çıkarıp atomik "bileşen seviyesine" ( Micro Layout ) taşıyarak modern mimariyi yeniden tanımlar.

Bu sayede, aynı modülün ( bir ürün kartı veya haber bileşeninin ); hem dar bir yan menüde ( sidebar ) hem de geniş bir ana içerik alanında ( main content ), hiçbir ekstra sınıf isimlendirmesine veya karmaşık medya sorgusuna ihtiyaç duymadan, otomatik olarak bulunduğu yere adapte olmasını ve farklı görünmesini mümkün kılar.

Geleneksel @media sorguları, tasarım kararlarını verirken her zaman ve sadece tarayıcı penceresinin toplam genişliğini referans alır; bu durum bileşenlerin içinde bulundukları dar alanları görmezden gelmesine, tabiri caizse bir "mekansal körlük" yaşamasına neden olur.

Düşünün ki mükemmel tasarlanmış bir "Kart Bileşeni"niz var, eğer bu kart, geniş bir masaüstü ekranında

( viewport > 1200 piksel ) dururken, tasarım gereği dar bir kenar çubuğuna yerleştirilirse; @media sorgusu ekranın hala büyük olduğunu algıladığı için karta ısrarla "geniş ekran stilini" ( yan yana üç sütunlu düzen ) uygulamaya çalışır.

Sonuç olarak, kart kendisine ayrılan dar alana sığmaz, düzen patlar ve içerik okunamaz hale gelir; çünkü @media, bileşenin sıkıştığı dar hücreye bakmaz, sadece ekranın ( dünyanın ) ne kadar büyük olduğuna bakar.

Kapsayıcı sorguları (@container), bu paradoksu çözmek için odağı global ekrandan alıp, doğrudan bileşenin kendisine ev sahipliği yapan kapsayıcının fiziksel alanına kilitler.

Aynı kart örneğinde; kart bir kenar çubuğunda dar bir alanda duruyorsa, bu alanın genişliği az olduğu için (ekran 4K bile olsa) kart otomatik olarak "Mobil Stilini" aktif eder ve içeriğini alt alta dizer.

Eğer aynı kart, kenar çubuğundan çıkarılıp geniş ana içerik alanına taşınırsa, alanı genişlediği için anında ve otomatik olarak "Masaüstü Stilini" geri kazanır; bu da bileşenin sayfadaki konumundan bağımsız olarak her yerde doğru çalışmasını sağlayan maksimum taşınabilirliği (portability) garanti eder.

Kapsayıcı sorgularını kullanmak için zorunlu olan ilk adım; bir HTML öğesini sıradan, pasif bir kutu olmaktan çıkarıp, kendi sınırları içinde gerçekleşen değişiklikleri izleyen ve raporlayan aktif bir "kapsayıcıya" dönüştürmektir.

Bu işlem, sorgulanacak ebeveyn öğeye container-type özelliği atanarak yapılır; bu özellik tarayıcı motoruna

"Dikkat, bu element artık sadece bir kutu değil, altındaki çocukları için bir referans ve sorgulama noktasıdır" talimatını veren resmi bir deklarasyondur.

/* Kapsayıcıyı Tanımlama */
.sidebar {
    container-type: inline-size; /* Genişliği izle */
    container-name: sidebar-area; /* (İsteğe bağlı) İsim ver */
}

container-type: inline-size; En yaygın ve pratik kullanılan değerdir.

Kapsayıcının "mantıksal genişliğine" ( yazı akış yönündeki boyuta) göre sorgulama yapılacağını belirtir.

Bu sayede, kapsayıcının width değeri değiştiğinde, içindeki elementlerin buna tepki vermesi sağlanır.

container-name: isim; Bu özellik teknik olarak isteğe bağlı olsa da, sayfada birden fazla sorgulanabilir alanın iç içe geçtiği

( bir sidebar ve onun içindeki bir widget ) karmaşık mimarilerde karışıklığı önlemek ve spesifik bir ata öğeyi hedeflemek için mantıklıdır.

Kapsayıcı tanımlandıktan sonra, alt öğelerin stilleri @container kuralı kullanılarak koşullandırılır.

Sözdizimi yapısal olarak @media ile neredeyse aynıdır; ancak buradaki kritik fark, genişlik referansının ( min-width ) global viewport değil, az önce tanımladığımız kapsayıcının kendisi olmasıdır.

/* Kullanımı: Eğer 'sidebar-area' 300px'den büyükse */
@container sidebar-area (min-width: 300px) {
    .card {
        display: flex; /* Yan yana diz */
    }
}

Bu sayede, stil kuralları varsayımlara değil, bileşenin içinde bulunduğu alanın gerçek fiziksel ihtiyacına göre uygulanır.

Kapsayıcı sorguları, sadece stil değiştirme yeteneğiyle kalmaz; aynı zamanda boşluk ve boyutlandırma matematiğini global ekrandan koparıp yerelleştiren yeni, kapsamlanmış (scoped) göreceli birimler sunar (cqw, cqh, cqi, cqb).

cqw (Container Query Width): Tanımlı kapsayıcının genişliğinin %1'ine eşittir.

Bu birimler sayesinde, bir font boyutu veya padding değeri, viewport'tan tamamen bağımsız olarak, sadece ve sadece ait olduğu

bileşenin boyutuna göre ölçeklenir.

Bu yerel matematik, bir bileşenin iç fontlarının, büyük bir ekranda bile dar bir kutuya ( sidebar ) sığarken orantılı olarak küçülmesini sağlayarak, klasik vw biriminin yol açtığı "dar alanda devasa font" ( aşırı ölçeklenme) sorunlarını kökten ortadan kaldırır.

@container özelliği, modern Bileşen Tabanlı Tasarım (Component-Based Design) felsefesini CSS seviyesinde tam ve yerel olarak destekleyen ilk özelliktir.

Bir bileşen, sitenin herhangi bir yerine ( üstbilgiye, altbilgiye veya bir modal pencereye ) taşındığında; tüm duyarlı stil kurallarını ve adaptasyon zekasını kendi içinde taşıdığı için, dışarıdan hiçbir müdahaleye veya "override" koduna gerek kalmadan her zaman doğru görünür.

Bu durum, kodun yeniden kullanılabilirliğini ( reusability ) ve sürdürülebilirliğini radikal bir şekilde artırarak, "Bir kere yaz, her yerde kullan" prensibini gerçeğe dönüştürür.

Teknik bir kısıtlama olarak; bir kapsayıcı, kurallar koyduğu kendi alt öğelerinin ( çocuklarının ) stillerini değiştirebilir, ancak kendi stillerini sorgulayarak değiştiremez.

Bu kural (kendini sorgulama yasağı), tarayıcı motorunda oluşabilecek sonsuz döngüleri (circular dependency) engellemek için getirilmiş kritik bir spesifikasyon kısıtlamasıdır.

Eğer bir öğe kendi genişliğini sorgulayıp buna göre kendi genişliğini değiştirebilseydi ( padding ekleyerek), bu durum genişliğin değişmesine, değişen genişliğin sorguyu tekrar tetiklemesine ve tarayıcının sonsuza kadar boyut hesaplamasına yol açardı.

Media Queries Level 5 spesifikasyonu, CSS'in yıllardır süregelen tasarım felsefesini sadece

"cihazın fiziksel boyutunu sorgulamaktan" radikal bir şekilde ayırıp; tasarımın merkezine "kullanıcının kişisel deneyim tercihini" yerleştiren tarihi bir dönüm noktasıdır.

Bu yeni yaklaşım, tarayıcıya "Ekranın kaç piksel?" diye sormak yerine; "Kullanıcının ışığa duyarlılığı var mı?",

"Animasyonlardan rahatsız oluyor mu?" veya "Veri tasarrufu yapmak istiyor mu?" gibi, makineden çok insanı anlamaya yönelik sorular sorarak arayüzü şekillendirir.

Bu yeniliklerin çoğu, webin sadece "görünebilir" olmasını değil, herkes için "kullanılabilir" olmasını sağlayan erişilebilirliği artırmayı temel misyon edinmiştir.

Aynı zamanda, gereksiz görsel yükleri azaltarak veya kullanıcının sistem ayarlarına ( pil tasarrufu moduna ) saygı duyarak, donanım kaynaklarını verimli kullanan ve performansı optimize eden daha etik bir web tasarımı anlayışını mümkün kılar.

@keyframes kuralı, CSS'in statik doğasını kıran ve bir elementin zaman içindeki değişimini yöneten; bir animasyon sekansının (dizisinin) tamamını, o hareketin en kritik anlarındaki (anahtar karelerdeki) stillerini tek tek tanımlayarak oluşturan temel yapı taşıdır.

Bu kural, tarayıcıya sadece "Başla" ve "Bitir" demekle kalmayıp; animasyonun başlangıcında, ortasında, bitişinde ve aradaki herhangi bir yüzdelik diliminde bir öğenin tam olarak hangi stile ( renk, konum, şeffaflık vb. ) sahip olması gerektiğini söyleyen ayrıntılı ve deterministik bir yol haritasıdır.

Teknik olarak @keyframes, animasyonun "dönüm noktalarını" belirler.

Siz sadece %0 ve %100 noktalarındaki durumları tanımlarsınız; tarayıcı motoru ise bu iki nokta arasındaki milyonlarca ara kareyi matematiksel olarak hesaplayarak (interpolation) akıcı ve kesintisiz bir hareket yanılsaması yaratır.

En temel kullanım senaryosunda @keyframes, bir öğenin var olduğu ilk durum ( başlangıç pozisyonu ) ile ulaşması gereken son durum

( bitiş pozisyonu ) arasındaki tek ve kesintisiz bir yumuşak dönüşümü tanımlar.

Bu mekanizma, basitçe "A noktasından B noktasına git" komutunu içerir ve tarayıcıya bu iki uç nokta arasındaki tüm fiziksel değişimleri hesaplama görevini yükler.

Bir animasyonun teknik iskeleti, ona verilen isim ve zaman duraklarından oluşur:

/* Basit Fade-In Efekti */
@keyframes gorunur-ol {
    from { opacity: 0; } /* Başlangıç */
    to   { opacity: 1; } /* Bitiş */
}

[isim]: Animasyona geliştirici tarafından verilen ve daha sonra CSS'teki animation-name özelliği ile çağrılacak olan, o hareket dizisinin

benzersiz kimlik kartıdır (ID); Türkçe veya İngilizce olabilir ancak boşluk içermemelidir.

from ve to: Bu anahtar kelimeler, animasyonun zaman çizelgesindeki mutlak uçları temsil eder; from zamanın sıfır noktasını (%0), to ise zamanın tamamlandığı son noktayı (%100) ifade eden semantik takma adlardır.

Bir düğmenin fare üzerine gelindiğinde rengini değiştiren reaktif (tepkisel) bir transition işleminden farklı olarak; @keyframes, öğeyi kullanıcı müdahalesi olmadan, sayfa yüklendiği anda veya bir sınıf eklendiğinde otomatik ve otonom olarak hareket ettiren bağımsız bir kurgu başlatır.

Bir şirket logosunun sayfa açılışında opaklığını 0'dan 1'e getirerek yavaşça belirmesini sağlayan bir "Fade-in" efekti, bu yapının en klasik örneğidir.

Bu seviye, animasyon kurgusunu basit bir "başlangıç-bitiş" ikileminden çıkarıp; animasyonun toplam süresini hassas bir zaman çizelgesi (timeline) gibi yöneterek, yüzdelik dilimler ( %0, %25, %50, %100 ) aracılığıyla öğenin birden fazla ara durumdan geçmesini sağlayan sofistike bir yapı sunar.

from ve to anahtar kelimeleri yerine kullanılan bu yüzdelik değerler, geliştiriciye animasyonun akışı üzerinde milimetrik bir kontrol ve hikaye anlatımı gücü verir.

Bu yapı, animasyonun tek bir nefeste değil, bir süreç boyunca farklı karakterlere bürünmesini sağlar.

Karmaşık bir hareket senaryosunda; bir karenin %0 anında ekranın solunda sakince dururken, %50 anında yukarıya fırlayıp kendi ekseni etrafında dönmesi ve nihayet %100 anında sağ tarafa yumuşakça inmesi gibi çok aşamalı bir eylem dizisi tanımlanabilir.

Sizin tanımlamadığınız ara yüzdelik dilimler (örneğin %25 ile %50 arası) arasındaki geçişi, tarayıcı motoru yine otomatik matematiksel hesaplamalarla ( interpolasyon ) doldurarak akıcı ve kesintisiz bir hareket sağlar.

Mühendislik açısından kritik bir detay olarak; @keyframes içinde tanımlanan özellikler rastgele seçilmemeli, tarayıcının ana işlemcisini (CPU) yormadan doğrudan Grafik İşlemci (GPU) üzerinde hızlandırılabilen (Hardware Acceleration) özellikler tercih edilmelidir.

Bu bağlamda en verimli özellikler; sayfa düzenini (layout) yeniden hesaplatıp pikselleri tekrar boyamayı gerektirmeyen transform (konum değiştirme, büyütme, döndürme) ve opacity (saydamlık) özellikleridir; bunlar "saniyede 60 kare" ( 60fps ) akıcılığına ulaşmanın anahtarıdır.

@keyframes ile animasyonun "ne yapacağı" ( senaryo ) tanımlandıktan sonra; bu pasif tanımın sayfadaki bir öğe üzerinde ne kadar süreyle, hangi sıklıkta, hangi hız eğrisiyle ve hangi yönde çalışacağını belirleyen CSS animation özellikleri (rejisör komutları) ile aktif edilerek kontrol edilmesi zorunludur.

Süreklilik (animation-iteration-count): Bir animasyonun tek seferlik bir olay mı yoksa sonsuz bir döngü mü olacağını belirler.

Özellikle infinite değeri, bir yükleme simgesinin (spinner) veya arka plan efektinin durmaksızın çalışmasını sağlayan "perpetual motion" (sürekli hareket) mekanizmasını kurar.

Yön Yönetimi (animation-direction): Animasyonun akış yönünü manipüle eder.

alternate değeri, animasyonun bir sarkaç gibi davranmasını sağlar; birinci döngüde A'dan B'ye giderken, ikinci döngüde B'den A'ya geri döner. Bu teknik, animasyonun bitiş ve başlangıç noktaları arasındaki o sert ve istenmeyen "zıplamayı" ( jump cut ) engelleyerek akıcı ve organik bir görünüm sunar.

Performans mühendisliği açısından hayati bir kural şudur: @keyframes ile bir stil değişimi tanımlandığında, tarayıcı bu değişimin her karesini ( frame ) saniyeler içinde defalarca yeniden çizmek zorundadır.

Bu nedenle, sayfa düzenini (Layout) değiştiren ve işlemciye (CPU) ağır yük bindiren width , height , margin , padding gibi özellikleri animasyon içinde kullanmaktan şiddetle kaçınılmalıdır.

Bunun yerine, doğrudan Grafik İşlemci (GPU) tarafından işlenen ve "Composite" katmanında gerçekleşen transform (translate, scale, rotate) özelliklerini kullanmak; tarayıcının iş yükünü hafifletir ve animasyonun takılmadan, yağ gibi akan 60 FPS ( saniyede 60 kare ) standardında olmasını garantiler.

@keyframes kuralı, standart CSS öncelik savaşlarından bağımsız, izole bir alanda tanımlanır; yani diğer global stillerle doğrudan bir çakışma yaşamaz, sadece çağrıldığı isim üzerinden otonom bir bölge yaratır.

Önemli bir detay olarak; animasyon bittiğinde öğe, varsayılan olarak animasyonun son karesindeki stili korumaz ve aniden başlangıçtaki

"Normal Akış" stiline geri döner (bu davranışı değiştirmek ve son karede kalmasını sağlamak için animation-fill-mode: forwards; kullanılır).

@font-face kuralı, web tasarımının ilk yıllarındaki kısıtlayıcı "güvenli yazı tipleri" (web-safe fonts) dönemini kapatan; tarayıcıya, kullanıcının yerel işletim sisteminde fiziksel olarak yüklü olmayan özel bir yazı tipi dosyasını (web font) uzak sunucudan indirip, siteye dahil etme (embed) talimatını veren kritik bir yönergedir.

Bu kural sayesinde, bir web sitesi artık kullanıcının bilgisayarında "Helvetica" veya "Arial" olup olmadığına bağımlı kalmadan; tasarımcının vizyonunda belirlediği o spesifik ve özgün yazı karakterini, tıpkı bir görseli yükler gibi ağ üzerinden kullanıcıya sunarak tipografik bağımsızlığını ilan eder.

Bu mekanizma, bir markanın görsel kimliğinin en önemli parçası olan tipografinin; Windows, macOS, Android veya Linux gibi farklı font kütüphanelerine sahip ekosistemlerde bile tutarlı ve bozulmadan görünmesini sağlayan CSS'in birincil estetik aracıdır.

@font-face, sadece bir dosya yükleme işlemi değil; sitenin karakterini oluşturan harf yapılarının (gliflerin), kullanıcının cihazına geçici olarak ödünç verilmesi ve tarayıcı motoru tarafından doğru şekilde render edilmesi (çizilmesi) sürecini başlatan teknik bir köprüdür.

Bu seviye, tarayıcıya özel bir yazı tipini yüklemesi ve tanıması için gereken asgari teknik bilgileri sağlayan bir "kayıt protokolüdür".

Kritik bir ayrım olarak; @font-face kuralının kendisi doğrudan hiçbir HTML öğesine stil uygulamaz veya sayfayı boyamaz; sadece yeni bir font kaynağını sisteme tanıtır, onu bir isimle tesciller ve tarayıcının kullanımına hazır bir "rezerv" olarak sunar.

Bir fontu sisteme tanıtmak için iki zorunlu bileşene ihtiyaç vardır: Ona vereceğimiz bir "iç isim" ve dosyanın bulunduğu "fiziksel adres".

/* Fontu Sisteme Tanıtma */
@font-face {
    font-family: 'MarkaFontum'; /* Bizim verdiğimiz takma ad */
    src: url('fonts/marka-bold.woff2') format('woff2'); /* Dosya konumu */
}

font-family (İsim Atama): Bu özellik, fontun orijinal dosya adından bağımsız, CSS evreninde geçerli olacak benzersiz kimliğidir. Buraya atadığınız isim (örneğin 'MarkaFontum'), tamamen geliştiricinin inisiyatifindedir ve daha sonraki stil tanımlarında bu varlığı çağırmak için kullanılacak olan

anahtar kelimedir.

src (Kaynak Belirtme): Tarayıcıya font dosyasının sunucudaki tam konumunu (url()) ve dosyanın teknolojik formatını (format()) bildiren zorunlu yol haritasıdır.

Tanımlanan font, ancak sayfanın herhangi bir yerinde font-family: 'MarkaFontum', Arial, sans-serif; şeklinde çağrıldığında aktifleşir ve indirme işlemi başlar.

Yedek Stratejisi: Font listesinde özel ismin hemen ardından virgülle ayrılmış standart sistem fontlarını (Arial, sans-serif) eklemek, web tipografisinin emniyet kemeridir.

Eğer özel font dosyası sunucu hatası veya yavaş bağlantı nedeniyle yüklenemezse, tarayıcı paniklemeden sıradaki yedeği devreye sokar ve içeriğin

okunabilir kalmasını garanti eder.

Erken CSS döneminde ve özellikle web tipografisinin emekleme aşamasında, tarayıcı ekosistemi adeta dilleri birbirine karışmış bir Babil Kulesi gibiydi; Internet Explorer sadece kendi tescilli formatını (.eot) tanırken, diğer modern tarayıcılar (Firefox, Safari) farklı standartları (.ttf, .otf, .svg) benimsiyordu.

Bu teknolojik bölünme, bir fontun "tek bir dosya" ile tüm kullanıcılarda çalışmasını imkansız kılıyor ve geliştiricileri her tarayıcı motorunun anlayacağı dilden konuşmaya zorluyordu.

Bu kaosu yönetmek ve fontun yüklenmeme riskini sıfıra indirmek için geliştiriciler, literatüre "Bulletproof Syntax" (Kurşun Geçirmez Sözdizimi) olarak geçen defansif bir kodlama stratejisi geliştirmek zorunda kaldılar.

Bu yöntem, bir fontu web'e yüklemenin son derece karmaşık, şişkin ve yönetilmesi zor bir yolu olsa da; o dönemin parçalı pazarında %100 uyumluluğu sağlamak için tek bir font ailesi altında birden fazla dosya formatını sırayla ve yedekli olarak yığmayı gerektiren kaçınılmaz bir mühendislik zorunluluğuydu.

/* Tarihsel "Bulletproof" Yöntem */
@font-face {
    font-family: 'Fontum';
    src: url('font.eot'); /* IE9 Uyumluluk Modu */
    src: url('font.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
         url('font.woff') format('woff'), /* Modern Tarayıcılar */
         url('font.ttf')  format('truetype'), /* Safari, Android, iOS */
         url('font.svg#svgFontName') format('svg'); /* Eski iOS */
}

Bu seviye, web fontlarının yalnızca görsel bir dekorasyon aracı olmadığını; aynı zamanda Core Web Vitals (CLS - Kümülatif Düzen Kayması) gibi modern performans metriklerini doğrudan etkileyen kritik bir yükleme süreci olduğunu kabul eder.

Font dosyası ağ üzerinden indirilirken tarayıcının metni kullanıcıya nasıl sunacağı, geliştiricileri iki zorlu senaryo arasında seçim yapmaya zorlar: Metnin font yüklenene kadar tamamen görünmez kalması ( FOIT: Flash of Invisible Text ) veya geçici olarak sistem fontuyla görünüp aniden değişerek düzeni kaydırması ( FOUT: Flash of Unstyled Text ).

font-display özelliği, geliştiricilere bu kaotik yükleme sürecini yönetme ve tarayıcıya "bekleme toleransını" bildirme gücü veren bir kontrol mekanizmasıdır.

Swap (Kullanıcı Odaklı): En yaygın ve önerilen çözümdür; tarayıcıya bir talimat verir;

"Özel fontum yüklenene kadar kullanıcıyı bekletme, hemen yerel bir yedek fontla içeriği göster" bu talimat her koşulda okunabilir kalmasını (FOUT pahasına) garanti eder.

Block (Tasarım Odaklı): Font yüklenene kadar metni kısa bir süre görünmez kılar; bu, fontun aniden değişip dikkat dağıtmasını engeller ancak bağlantı yavaşsa kullanıcının boş bir sayfaya bakmasına (FOIT) neden olabilir.

Optional (Performans Odaklı): Eğer font milisaniyeler içinde çok hızlı yüklenmezse, tarayıcı özel fontu indirmekten tamamen vazgeçer ve performansı önceliklendirerek sonsuza kadar yedek fontu kullanır.

Font dosyaları genellikle sitenin açılışını geciktiren "render-blocking" kaynaklardır; bu nedenle dosya boyutunu küçültmek için fontun içindeki kullanılmayan binlerce karakteri ( Çince glifleri ) atıp, sadece hedef dildeki karakterleri barındıran Alt Kümeler oluşturmak hayati bir optimizasyondur.

Ayrıca, HTML tarafında <link rel="preload"> etiketi kullanarak, tarayıcının font dosyasını stil dosyasını beklemeden

erkenden indirmeye başlaması sağlanır, böylece fontlar ihtiyaç duyulduğu anda hazır olur.

Modern Strateji: Günümüzde tarayıcı pazarının %98'i üstün sıkıştırma teknolojisine sahip

WOFF2 formatını desteklediği için; artık eski TTF/EOT formatlarını içeren "Bulletproof" kod yığınlarını yazmak yerine, sadece tek bir WOFF2 dosyası sunmak ve eski tarayıcıları sistem fontuna ( fallback ) bırakmak, en verimli ve temiz mühendislik yaklaşımıdır.

@supports kuralı, modern web geliştirme süreçlerinde dışsal bir script'e veya JavaScript tabanlı kütüphanelere (örneğin Modernizr) ihtiyaç duymadan; tarayıcı motorunun belirli bir CSS özelliğini ve o özelliğe ait değeri teknik olarak destekleyip desteklemediğini, çalışma anında (runtime) kontrol etmenizi sağlayan koşullu ve yerel (native) bir At-Kuralıdır.

Bu mekanizma, CSS'in sadece stil tanımlayan pasif bir dil olmaktan çıkıp; kendi çalışma ortamını analiz eden, tarayıcının yetenek haritasını çıkaran ve bu yeteneklere göre kodun işleyişini dinamik olarak değiştiren "öz-farkındalığa" (self-awareness) sahip akıllı bir yapıya dönüşmesini temsil eder.

Geliştiriciler için bu kural, yeni ve deneysel CSS özelliklerini (örneğin subgrid veya yeni renk uzayları) kullanırken "Ya kullanıcının tarayıcısı bunu desteklemiyorsa?" endişesini ortadan kaldıran bir güvenlik ağıdır; çünkü desteklenmeyen kod bloğu tarayıcı tarafından tamamen görmezden gelinir ve bu sayede sitenin çökmesi veya bozulması engellenir.

@supports kuralı, tarayıcının ekran boyutunu veya fiziksel yönünü sorgulayan @media kuralının aksine; tarayıcı motorunun (rendering engine) teknik kapasitesini ve kelime dağarcığını sorgulayan bir iç denetim mekanizmasıdır.

Çalışma prensibi oldukça nettir: Eğer tarayıcı, parantez içinde sorulan CSS özelliğini ve değerini tanıyor ve doğru buluyorsa, o bloğun içindeki stilleri işleme alır; aksi takdirde, tanımadığı bir komutu çalıştırmaya zorlanıp hata vermek yerine, tüm stil bloğunu güvenli bir şekilde yok sayar .

Bu basit yapı, CSS gibi deklaratif (bildirimsel) bir dile, programlama dillerinden aşina olduğumuz güçlü bir "Eğer-O zaman" (If-Then) mantığını entegre eder.

/* Eğer tarayıcı Grid'i destekliyorsa bu bloğu çalıştır */
@supports (display: grid) {
    .container {
        display: grid;
        grid-template-columns: repeat(3, 1fr);
    }
}

Bu kuralın varoluş nedeni ve temel felsefesi Aşamalı Geliştirme prensibidir.

Geliştiriciler, önce eski-yeni tüm tarayıcıların sorunsuz çalıştıracağı temel, sağlam ve erişilebilir bir stil katmanı oluşturur; ardından @supports bloğu kullanarak modern ve ileri düzey özellikleri ( gölgeler, 3D dönüşümler, yeni düzen sistemleri ) bu temelin üzerine bir "makyaj katmanı" olarak eklerler.

Bu strateji, eski cihazları kullananların içeriğe sorunsuz erişmesini ( temel görünümle ) sağlarken, modern tarayıcı sahiplerinin

"ekstra görsel zenginlikleri" görmesini sağlar; böylece tasarım en kötü teknolojik koşulda bile asla bozulmaz.

@supports kuralı, tıpkı gelişmiş bir programlama dilindeki ( JavaScript veya Python gibi ) koşullu ifadeler gibi güçlü

mantıksal operatörler ( not, and, or ) kullanarak, en karmaşık tarayıcı uyumluluk senaryolarını bile tek bir CSS dosyası içinde yönetme imkanı sunar.

Bu operatör, @supports kuralının en stratejik ve hayati kullanım alanını oluşturur: Bir özelliğin desteklenip desteklenmediğini değil, desteklenmediği durumu (negatif koşulu) hedefleyerek, eski teknolojiler için güvenli bir geri dönüş mekanizması kurar.

Kullanım Senaryosu: Örneğin, modern display: grid düzenini kullanmak istediğimizde; @supports not (display: grid) ifadesi tarayıcıya "Eğer Grid sistemini teknik olarak desteklemiyorsan, o zaman eski usul float: left ve width: 33% stillerini devreye sok" talimatını vererek, eski tarayıcılarda dahi sayfa düzeninin çökmesini engelleyen güvenli ve temiz bir köprüleme sağlar.

/* Grid desteklemeyenler için B Planı */
@supports not (display: grid) {
    .kutu { float: left; width: 33.333%; }
}

And (Zorunlu Birliktelik): Birden fazla özelliğin aynı anda desteklenmesini şart koşar.

Bu, bir görsel efektin ( hem backdrop-filter hem de transform) hatasız çalışması için iki farklı teknolojinin birlikte var olmasının zorunlu olduğu katı senaryolarda kullanılır.

Or (Esneklik ve Alternatif): İki veya daha fazla özellikten en az birinin desteklenmesini yeterli bulur. Özellikle tarayıcıların standart isimler ve vendor prefix'ler ( -webkit-, -moz- ) arasında gidip geldiği geçiş dönemlerinde, "Ya standart olanı ya da Webkit versiyonunu destekle" diyerek kapsama alanını genişletmek için son derece verimlidir.

@supports kuralının modern web performansına en büyük stratejik katkısı; tarayıcı desteğini ve özellik yeteneklerini kontrol etmek için yıllardır endüstri standardı olarak kullanılan ve ek HTTP isteği yaratan Modernizr gibi harici JavaScript kütüphanelerine olan zorunlu bağımlılığı tamamen ortadan kaldırmasıdır.

Bu yapısal değişim, istemci tarafındaki ( client-side ) script ayrıştırma yükünü ve işlemci maliyetini radikal bir şekilde azaltarak sayfa açılışını hızlandırır; aynı zamanda CSS'i dışarıdan yardım bekleyen pasif bir dosya olmaktan çıkarıp, kendi mantığını yürütebilen kendine yeterli

( self-contained ) ve bağımsız bir dil haline getirir.

Mimari açıdan bakıldığında bu kural; float tabanlı eski nesil düzenleme teknikleri ile grid gibi modern paradigmaların aynı CSS dosyasında, birbirlerinin ayağına basmadan, stil çatışması yaratmadan ve gereksiz tarayıcı önekleri ( prefixes ) kirliliği oluşturmadan barış içinde yaşamasını sağlayan diplomatik bir izolasyon katmanıdır.

Bu sayede, float gibi artık "yedek" olması gereken eski teknikler ana stil akışından ayrı tutularak kapsüllenir; kodun ana gövdesi her zaman okunaklı, modern ve amaca uygun kalırken, eski kodlar sadece ihtiyaç duyulduğunda ( fallback olarak ) devreye girer.

@supports kuralı, yüzeysel bir kontrolün ötesine geçerek; sadece özelliğin ( color veya display ) varlığını sorgulamakla yetinmez, aynı zamanda o özelliğe atanacak spesifik ve karmaşık bir değerin de tarayıcı motoru tarafından geçerli olup olmadığını derinlemesine denetler.

@supports (color: oklch(50% 0.1 250)) ifadesi; tarayıcının sadece "renk" özelliğini değil, en yeni ve geniş renk uzayı olan

OkLCH fonksiyonunu ve sözdizimini anlayıp anlamadığını milimetrik olarak kontrol ederek, en güncel CSS yeteneklerinin "patlama riski olmadan" en üst düzeyde ve güvenle kullanılmasını sağlar.

@layer kuralı, CSS'in en temel çalışma prensibi olan ancak büyük projelerde yönetilmesi en zor mekanizmaya dönüşen "Basamaklama" yapısını ehlileştirmek için; stil kodlarını rastgele yığınlar halinden çıkarıp, mantıksal ve yönetilebilir katmanlara (layers) ayıran, CSS'in en yeni ve devrim niteliğindeki At-Kuralıdır.

Bu özellik, stillerin çakıştığı durumlarda "Hangi stil kazanacak?" sorusunun cevabını, artık tarayıcının karmaşık matematiksel hesaplamalarına bırakmak yerine; doğrudan geliştiricinin belirlediği katman sıralamasına (önce "reset", sonra "framework", en son "tema" gibi) emanet eder.

Cascade Layers, stillerin geleneksel özgüllük ( specificity ) hesaplamalarından ( ID , Class , Tag puanları ) bağımsız bir şekilde uygulanmasını sağlayan bir yalıtım katmanıdır.

Yani, alt katmandaki çok güçlü bir ID seçicisi (#header), üst katmandaki basit bir sınıf seçicisi (.header) tarafından -özgüllük puanı düşük olsa bile- ezilebilir; çünkü artık patron "seçicinin gücü" değil, "katmanın sırası"dır.

Geleneksel CSS mimarisinde, birbiriyle çakışan iki stil kuralından hangisinin ekranda görüneceğini belirleyen tek yargıç Özgüllük Puanı (Specificity) idi; bu sistemde eğer bir bileşen stili (.button-primary), çok düşük puanlı ama geniş kapsamlı genel bir stil kuralı tarafından yanlışlıkla ezilirse, geliştirici bu çatışmayı çözmek için genellikle ID seçicileri kullanmak veya en kötüsü koda !important bombası atmak gibi "nükleer seçeneklere" başvurmak zorunda kalırdı.

Bu durum, projenin ilerleyen aşamalarında kodu karmaşıklaştıran, yönetilemez hale getiren ve geliştiriciler arasında bitmek bilmeyen

"stil savaşlarına" neden olan kaotik bir sarmaldı.

@layer kuralı ile bu güç dengesi tamamen değişir; geliştirici artık hangi stil grubunun daha baskın olacağını, seçicilerin matematiksel puanlarına bakılmaksızın en baştan belirleme yetkisine sahiptir.

Bu yeni düzende "Özgüllük", katmanlar arasındaki mutlak önceliği belirlemekten çıkarılıp, sadece aynı katmanın içindeki küçük çatışmaları çözmeye yarayan ikincil ve zayıf bir kural haline indirgenmiştir.

Katmanların hiyerarşisi, CSS dosyasının en başında tek bir satırla, bir "anayasa maddesi" gibi tanımlanır:

/* Öncelik Sıralaması (Soldan Sağa Artar) */
@layer reset, components, utilities;

Bu satır, tarayıcıya sadece üç farklı katman olduğunu söylemekle kalmaz, aynı zamanda bunların "kazanma sırasını" da belirler; bu sıralamada en soldaki reset en düşük ( ezilebilir ), en sağdaki utilities ise en yüksek (baskın) önceliğe sahiptir.

@layer sisteminin temel kuralı şudur: Sıralamada veya kod akışında en sonda tanımlanan katman, kendisinden önce gelen tüm katmanları

-içeriklerinin özgüllük puanı ne kadar yüksek olursa olsun- geçersiz kılar ve her zaman kazanır.

Yani yukarıdaki örnekte, utilities katmanındaki basit bir sınıf, reset katmanındaki karmaşık ve yüksek puanlı bir ID seçicisini bile zahmetsizce ezer.

Bu özellik özellikle, Bootstrap veya Tailwind gibi bir kütüphaneden gelen varsayılan tema stili ile kendi yazdığınız özel stil çakıştığında hayat kurtarır.

!important karmaşasına girmek yerine; kütüphane stillerini alt katmana (@layer library;), kendi özel stillerinizi üst katmana (@layer custom;) yüklediğinizde, sizin kodunuz otomatik olarak kütüphaneyi ezer ve geliştirici olarak kontrolü CSS'in matematiksel kurallarından alıp

kendi mimari kararınıza bağlamış olursunuz.

Orta seviye kullanım, @layer mekanizmasının CSS mimarisinde adeta sanal bir "klasörleme sistemi" gibi çalışarak; binlerce satırlık kaotik kodu tek bir monolitik dosya gibi değil, öncelikleri ve sınırları baştan belirlenmiş mantıksal bölümler (katmanlar) halinde yönetmemize olanak tanıyan mimari yüzünü gösterir.

Bu modüler yapı sayesinde, projenin en temel sıfırlama stillerini reset katmanına, buton veya kart gibi yapı taşlarını components katmanına ve tek amaçlı yardımcı sınıfları utilities katmanına izole ederek; hata ayıklama (debugging) sırasında arama alanını daraltır ve kodun bakım maliyetini radikal bir şekilde düşürürüz.

@layer kuralının en devrimci yanı; geleneksel CSS'in "kimin seçicisi daha güçlüyse o kazanır" ( ID > Class > Tag ) dogmasını yıkarak, stilin önceliğini seçicinin matematiksel gücünden koparıp tamamen katmanın sırasına bağlamasıdır.

Katmanlar Arası Üstünlük: Düşünün ki utilities katmanı components katmanından sonra (daha öncelikli) tanımlanmış olsun; bu durumda utilities içindeki çok basit bir etiket seçici (a), components içindeki çok karmaşık ve yüksek puanlı bir ID seçiciyi ( #menu .link ) dahi zahmetsizce ezip geçer, çünkü burada kral seçici puanı değil, katman hiyerarşisidir.

Ancak bu durum Özgüllük (Specificity) kavramının tamamen öldüğü anlamına gelmez; Özgüllük kuralları sadece

bir katmanın kendi sınırları içine hapsedilmiştir.

Yani, aynı katman içinde yer alan iki çakışan kuraldan hangisinin kazanacağına, yine geleneksel ID ve Class puanları karar verir; fakat bu puanların gücü asla katman duvarlarını aşıp diğer katmanları etkileyemez.

Bu özellik, Bootstrap veya bir Reset CSS gibi harici kütüphaneleri kasıtlı olarak en düşük öncelikli katmana (@layer reset;) hapsederek yönetmeyi inanılmaz kolaylaştırır.

Böylece, kütüphanenin varsayılan stillerini değiştirmek (override) istediğimizde, kendi kodumuzda yapay olarak yüksek özgüllük (!important veya zincirleme sınıflar) kullanma zorunluluğu ortadan kalkar; çünkü bizim katmanımız hiyerarşik olarak üstte olduğu için doğal bir üstünlüğe sahiptir.

CSS mimarisinde Cascade (Basamaklama), stillerin kaynağına (kullanıcı, tarayıcı veya yazar), bağlamına ve özgüllük puanına göre uygulandığı katı bir öncelik sırasıdır; @layer özelliği, bu basamaklama kurallarının en kritik aşamalarından birini, yani özgüllük hesaplamasından hemen önceki "karar anını" ele geçirerek yeniden tanımlar.

Bu devrimsel özellik, geliştiricinin tarihte ilk kez, z-index gibi görsel bir katmanlama aracıyla değil, doğrudan bir At-Kuralıyla stil önceliğini programatik olarak yönetme yeteneği kazanması anlamına gelir; bu kontrol, kaotik ve büyük ölçekli uygulamaların karmaşıklığını yönetmek için mutlak bir gerekliliktir.

Geleneksel CSS'te !important kuralı, tüm Basamaklama kurallarını ezen ve genellikle çaresizlik anında kullanılan "nükleer bir buton" iken, uzun vadede projenin bakımını imkansız kılan bir karmaşa kaynağıydı; ancak @layer ekosistemi içinde bu güç dengesi şaşırtıcı bir şekilde tersine döner.

Zayıflayan Güç: Yeni katmanlı yapıda, !important kullanımı artık en üst düzey ve mutlak güce sahip değildir; bu durum geliştiricileri bu etiketi kullanırken iki kez düşünmeye zorlayan, kaotik kullanımı zorlaştıran ve daha temiz çözümlere yönlendiren yeni ve disipline edici bir kural setidir.

@layer kuralı kullanılmadan, dosyanın herhangi bir yerine yazılan standart CSS kuralları, sistem tarafından otomatik olarak isimsiz ve en yüksek öncelikli bir katmana atanır.

Öncelik Güvencesi: Tarayıcı, bu isimsiz katmanları, açıkça tanımlanan ( @layer components; ) tüm katmanlardan daha sonra ve dolayısıyla

daha yüksek öncelikli olarak işler; bu kritik mekanizma, projenin eski kodlarının yeni katmanlı yapı kurulduktan sonra yanlışlıkla ezilmesini engelleyerek geriye dönük uyumluluğu garanti eder.

Modern Front-End mimarilerinde ve özellikle Bileşen Tabanlı Tasarım süreçlerinde, @layer kullanılarak stiller rastgele değil, risk seviyesine göre stratejik katmanlara ayrılır.

Örneğin; en zararsız ve temel olan "Sıfırlama" (reset) stilleri en alta, kararlı kalması gereken "Bileşenler" ortaya ve en agresif/değişken olan "Yardımcı Sınıflar" en üste yerleştirilerek; kodun uzun vadeli sürdürülebilirliği, hata ayıklama kolaylığı ve farklı ekiplerin aynı dosyada çalışabilmesi sağlanır.

@import kuralı, web tasarımının monolitik (tek parça) yapısını kıran; CSS motoruna, işlenmekte olan mevcut stil sayfasının içine, sunucudaki başka bir harici CSS dosyasını getirip entegre etmesi (include) talimatını veren özel bir At-Kuralıdır.

Bu komut, HTML tarafında <link> etiketi kullanmaya gerek kalmadan, doğrudan CSS dosyasının kendi içinden başka stil kaynaklarını zincirleme bir şekilde yükleyerek bağlantı kurmasını sağlar.

Bu yapısal mekanizma, binlerce satırlık yönetilemez ve devasa bir stil dosyasını tek bir blok halinde tutmak yerine; onu renkler, tipografi, düzen ve bileşenler gibi mantıksal olarak daha küçük parçalara bölmek için kullanılır.

Böylece geliştirici, projeyi küçük ve anlamlı modüller halinde (header.css, footer.css vb.) geliştirirken; tarayıcı tarafında bu parçalar tek bir ana dosya üzerinden birleştirilerek sunulur.

@import kuralı, temel işlev olarak bir CSS dosyasının içinden, başka bir harici CSS dosyasının tüm içeriğini çağırıp dahil etmeye yarar.

Bu mekanizma, projeyi devasa ve okunması imkansız tek bir CSS dosyasına hapsetmek yerine; kodunuzu mantıksal olarak reset.css, typography.css, header.css gibi küçük, odaklanmış ve yönetilebilir parçalara bölmenizi ve ardından bu parçaları tek bir

"Ana Stil Dosyasında" birleştirmenizi sağlayarak bakım kolaylığı sunar.

Tarayıcı bu komutu gördüğünde, belirtilen yoldaki dosyayı ağ üzerinden indirir ve içeriğini sanki o satıra elle kopyalanıp yapıştırılmış gibi ana dosyaya işler.

/* İki farklı yazım da geçerlidir */
@import url("styles/reset.css");
@import "styles/layout.css";

@import kuralının ihlal edilemez en katı kuralı şudur: Çağrıldığı CSS dosyasındaki tüm diğer stil kurallarından (örneğin body { color: blue; } gibi seçicilerden) önce, dosyanın en tepesinde (karakter seti tanımı hariç) yer alması mutlak bir zorunluluktur.

Eğer masumane görünen tek bir stil tanımı bile @import satırından önce yazılırsa, tarayıcı güvenlik ve ayrıştırma kuralları gereği @import komutunu tamamen yoksayar ve harici dosyayı yüklemeyi reddeder.

Bu kural aynı zamanda, yüklenecek stil dosyasının yalnızca belirli bir ortam koşulu altında uygulanmasını sağlamak için sonuna doğrudan bir medya sorgusu parametresi alabilir: @import url("print.css") print;.

Bu stratejik kullanım sayesinde, print.css dosyası sadece kullanıcı "Yazdır" komutunu verdiğinde veya baskı önizlemeye geçtiğinde devreye girer; böylece normal gezinti sırasında gereksiz bant genişliği kullanımı engellenmiş olur.

Bu seviye, @import kuralının kağıt üzerinde mantıksal ve modüler bir çözüm sunmasına rağmen, teknik mimaride tarayıcı performansını ve sayfa hızını neden sabote ettiğini açıklayan kritik bir mühendislik uyarısıdır.

Modern tarayıcılar, bir web sayfasını oluştururken (rendering path), kaynakları olabildiğince hızlı, verimli ve paralel olarak (aynı anda çoklu indirme) işlemeyi hedefler; ancak @import kuralı bu doğal akışı zorla durdurur ve verimsiz bir "istek zinciri" (request chain) oluşturur.

Bir tarayıcı, HTML içinde standart <link> etiketini gördüğünde CSS dosyasını anında indirmeye başlar; ancak @import ile çağrılan dosyalar için süreç böyle işlemez.

Tarayıcı önce birinci CSS dosyasını (Dosya A) tamamen indirmeli, açmalı ve satır satır okumalıdır; ancak bu okuma bittikten sonra "Dosya B'nin" varlığından haberdar olur ve indirme işlemini o an başlatır.

Sonuç: Bu ardışık ve birbirini bekleyen yükleme modeli (sequential loading), sayfanın ilk anlamlı boyama süresini (First Contentful Paint - FCP) ve etkileşim hızını ciddi şekilde geciktirir; çünkü tarayıcı zincirin son halkasındaki stil gelene kadar ekranı oluşturmayı beklemek zorunda kalır.

Performans ve hız optimizasyonunun en önemli öncelik olduğu günümüzde, çalışma zamanında @import kullanmak yerine iki ana yöntem endüstri standardı haline gelmiştir:

1. HTML <link> Kullanımı: Tüm CSS dosyalarını ayrı ayrı HTML <head> etiketi içinde standart <link> etiketiyle çağırmak, tarayıcının tüm dosyaları beklemeden paralel olarak indirmesini sağlar.

2. Ön İşlemci Derlemesi (Build Process): Geliştirme sırasında SASS veya LESS gibi ön işlemciler kullanarak, mantıksal olarak ayrılmış yüzlerce küçük CSS dosyasını, henüz sunucuya yüklemeden önce tek bir nihai (production) CSS dosyasına derlemek (compile) ve birleştirmektir.

Bu yöntem, hem kodun modülerliğini ve yönetim kolaylığını korur, hem de tarayıcıya sadece tek bir dosya sunarak performans için

en hızlı yüklemeyi garanti eder.

@namespace kuralı, CSS'in normalde standart ve basit HTML elementlerini hedeflerken karşılaşmadığı; ancak belge karmaşıklaşıp içine başka diller girdiğinde ortaya çıkan isim çakışmalarını (name collisions) önlemek ve yönetmek için kullanılan özel bir ayrıştırma protokolüdür.

Bu kural, tek bir HTML belgesi içine gömülmüş olan (embedded) XML tabanlı farklı işaretleme dillerinin (özellikle grafikler için SVG — Ölçeklenebilir Vektör Grafikleri ve bilimsel formüller için MathML — Matematiksel İşaretleme Dili) elementlerini, standart HTML etiketlerinden ayırarak benzersiz bir önek (prefix) veya varsayılan alan tanımı ile hedeflemeye yarar.

Bir web sayfasında hem bir HTML metin linki (<a>) hem de bir SVG grafiğinin içindeki link (<a>) bulunabilir; CSS'e sadece

a { color: red; } dediğinizde her ikisi de etkilenir.

@namespace kuralı sayesinde, "Ben sadece SVG dünyasındaki <a> etiketini kastediyorum" diyerek, CSS seçicilerinin kapsamını daraltabilir ve yanlış elementlerin boyanmasını engelleyebilirsiniz.

Bu kuralın varoluşsal nedeni, modern web sayfalarının artık saf ve homojen bir HTML yapısından ibaret olmayıp; içerisine XML tabanlı başka dillerden (SVG, MathML gibi) yabancı içeriklerin gömüldüğü "çok dilli" (poliglot) ve karmaşık bir yapıya evrilmiş olmasıdır.

Standart HTML yapısında <h1> veya <div> gibi etiket isimleri benzersiz ve bellidir; ancak SVG (Ölçeklenebilir Vektör Grafikleri) veya MathML (Matematiksel İşaretleme Dili) gibi XML kökenli diller devreye girdiğinde, farklı standartların tesadüfen aynı etiket ismini kullanması kaçınılmaz bir mühendislik karmaşası yaratır.

Düşünün ki, aynı belgenin içinde hem tarayıcı sekmesinde görünen HTML <title> etiketi, hem de bir SVG grafiğinin açıklamasını içeren SVG <title> etiketi yan <title> etiketi yan yana yaşamaktadır.

Eğer siz CSS dosyanızda sadece kaba bir title { color: red; } kuralı yazarsanız; CSS motoru hangi başlığı hedeflediğinizi ayırt edemez ve her iki etiketi de boyayarak bir isim çakışması krizine yol açar.

@namespace kuralı, tam bu noktada devreye girerek bu anlamsal belirsizliği ortadan kaldıran bir yargıç gibi davranır.

Bu mekanizma, farklı dillerden gelen elementlere benzersiz birer önek (prefix) atayarak; tarayıcıya

"Şu özel öneki gördüğünde ( svg|title ), sadece o dilin etiketlerini hedefle, diğer benzer isimli etiketlere dokunma" talimatını veren kesin bir ayrıştırma yöntemidir.

@namespace kuralının CSS mimarisindeki konumu rastgele değildir; dosyanın en tepesinde, yalnızca karakter seti kodlamasını belirleyen @charset kuralından hemen sonra ve diğer tüm stil tanımlarından, içe aktarmalardan önce tanımlanmak zorunda olan katı bir hiyerarşiye tabidir.

Bu kural, CSS motorunun ("parser") dosyayı okumaya başladığında, herhangi bir stil kuralını işlemeden önce bu özel uzay bilgisini tanımasını ve hafızasına almasını sağlamak için konulmuş mimari bir ön koşuldur.

Genel sözdizimi yapısı @namespace [önek] [URI]; şeklindedir; buradaki URI (Uniform Resource Identifier), o XML dilinin (örneğin SVG'nin) web'deki fiziksel adresi değil, uluslararası standartlarda belirlenmiş benzersiz ve resmi kimlik numarasıdır.

/* SVG Uzayını Tanımlama */
@namespace svg "http://www.w3.org/2000/svg";

/* Kullanımı: Sadece SVG içindeki rect'i boya */
svg|rect {
    fill: blue;
}

SVG Örneği: @namespace svg "http://www.w3.org/2000/svg"; satırı, tarayıcıya "Bundan sonra svg önekini gördüğün her yerde, bunu W3C'nin belirlediği bu resmi standartla eşleştir" talimatını vererek, tarayıcının SVG etiketlerini doğru şemayla tanımasını sağlar.

Tanımlanan önek, stil kurallarında elementin hemen önüne eklenen boru karakteri (|) ile birleştirilerek kullanılır (Örneğin: svg|rect).

svg|rect { fill: blue; } kuralı, tarayıcıya sadece ve sadece SVG isim uzayına (namespace) ait olan rect (dikdörtgen) etiketlerini hedeflemesini emreder; böylece belgenizde tesadüfen HTML tabanlı bir etiketi veya sınıfı olsa bile, o stil bundan asla etkilenmez ve stilin sadece ait olduğu dile uygulanması garanti altına alınır.

Bu kural, görsel bir CSS özelliğinden ziyade, web standartlarının daha derin, soyut ve mantıksal kavramlarını (Namespace, Cascade) yönetmek için kullanılan bir araçtır.

"İsim Uzayı" (Namespace), kökeni aslında C#, Java veya XML gibi katı kurallı programlama ve işaretleme dillerine dayanan; amacı, geniş bir kod elemanları kümesini (etiketler, sınıflar, fonksiyonlar) mantıksal olarak gruplayarak, onlara çakışmalardan uzak benzersiz bir kimlik ve soyad kazandırmak olan akademik bir kavramdır.

@namespace kuralı, bu resmi XML mantığını CSS dünyasına taşıyarak, özellikle farklı teknolojilerin iç içe geçtiği hibrit belgelerde kodun organizasyonunu, yalıtımını ve yönetilebilirliğini artırır.

Herhangi bir @namespace kuralı açıkça tanımlanmadığında, CSS seçicileri varsayılan ve örtük (implicit) olarak her zaman standart

HTML isim uzayını hedefler.

Bu nedenle, günlük hayatta sıradan div veya p etiketlerine stil verirken bu kurala asla ihtiyaç duymayız; çünkü CSS motoru varsayılan olarak onların HTML ailesine ait olduğunu bilir, ancak SVG veya MathML gibi "yabancı" diller belgeye dahil olduğunda bu kural bir zorunluluk haline gelir.

Teknik açıdan önemli bir detay olarak; @namespace kuralının kendisi veya bir seçiciye önek eklenmesi (örneğin svg|a), o kuralın CSS Öncelik (Specificity) puanına matematiksel bir katkı sağlamaz veya ekstra puan kazandırmaz.

Bu mekanizma, seçiciyi yalnızca belirlenen isim uzayının sınırları içine hapsederek daha kesin, cerrahi ve hatasız bir hedefleme sağlar; bu hassasiyet, stilin yanlışlıkla başka bir dilden gelen aynı isimli öğeye uygulanmasını önleyen bir filtreleme yöntemidir.

@document kuralı, CSS spesifikasyonlarının deneysel döneminde ortaya atılan; bir stil bloğunun tamamının, körü körüne her yerde değil, yalnızca tarayıcının o an görüntülediği sayfanın URL adresi (Uniform Resource Locator) belirli kriterleri ve koşulları sağladığında aktifleşip uygulanmasını hedefleyen özel bir At-Kuralıydı.

Bu kural, CSS'in normalde sadece HTML elementlerinin yapısına (DOM) bakan gözlerini; tarayıcının adres çubuğuna çevirmesini sağlayarak, stilin uygulanıp uygulanmayacağına bulunulan sayfanın adresine göre karar veren bir filtreleme mekanizması öneriyordu.

Bu mekanizmanın temel mühendislik amacı, CSS'e HTML belgesinin içeriğine veya sunucu taraflı kodlara (server-side code) fiziksel olarak müdahale etmeye gerek kalmadan; dışarıdan yüklenen tek bir dosya üzerinden, sadece belirli sayfalara (örneğin sadece "admin" paneline veya "iletişim" sayfasına) özgü URL bazlı koşullar ve stil özelleştirmeleri yapabilme yeteneği kazandırmaktı.

Bu kuralın temel varoluş amacı, CSS kodunu statik bir liste olmaktan çıkarıp, tarayıcının adres çubuğundaki URL verisine duyarlı, akıllı bir yapıya dönüştürmekti.

Geliştiriciler, sitenin tüm tasarım kodlarını (Main CSS) tek bir büyük ve merkezi dosyada tutarken; aynı zamanda o dosyanın içindeki belirli stil bloklarının sitenin hangi alt sayfasında (/hakkimizda, /blog vb.) devreye gireceğine karar verme yeteneğine, yani yerel bir yönetim gücüne sahip olmak istiyordu.

"Blog sayfasındayken yan çubuk mavi olsun, ancak İletişim sayfasına geçildiğinde aynı yan çubuk yeşile dönsün" gibi bağlama duyarlı bir komutu; HTML yapısını değiştirmeden veya sunucu taraflı kod yazmadan, sadece URL desenine bakarak vermeyi hedefliyordu.

Bu yapının sözdizimi, @document [fonksiyon] { ... } şeklinde kurulan ve tarayıcıya "Eğer adres çubuğundaki metin, parantez içindeki bu şartı (fonksiyonu) sağlıyorsa, süslü parantezler içine yazdığım özel CSS kodlarını uygula" talimatını veren koşullu bir sarmalayıcıdır.

url-prefix: Parantez içine yazılan değer ile başlayan tüm URL'leri hedefler (url-prefix("https://siteniz.com/blog/")). Bu fonksiyon, özellikle "Blog" kategorisi altındaki yüzlerce farklı makale sayfasının tamamı için geçerli olacak ortak bir stil şablonu oluşturmak adına ideal bir hiyerarşik filtreleme yöntemidir.

domain: Stilleri, sadece belirli bir alan adı (domain("siteniz.com")) ve onun tüm alt sayfalarıyla eşleştiğinde uygular; bu genellikle tarayıcı eklentileri veya kullanıcı stilleri (user styles) yazılırken, stilin yanlışlıkla başka sitelerde çalışmasını engellemek için kullanılır.

Bu kural, kağıt üzerinde sunduğu büyüleyici mantıksal kolaylığa ve merkezi yönetim vaadine rağmen; modern web ekosisteminden tamamen kaldırılmış ve rafa kaldırılmış olmasının arkasında, göz ardı edilemeyecek kadar derin teknik ve etik nedenler yatar.

@document kuralı, W3C'nin çalışma taslaklarında bir süre umut vaat ederek yer almış olsa da; güncel ve büyük tarayıcı motorları tarafından, yarattığı riskler nedeniyle standart olarak hiçbir zaman tam, kararlı ve tutarlı bir destek görmemiş ve sonuç olarak resmi olarak terk edilmiştir (deprecated).

Bu kuralın standartlardan aforoz edilmesinin ana ve en hayati nedeni, siber güvenlik uzmanlarının işaret ettiği

kullanıcı gizliliği (privacy) kaygılarıydı.

Harici ve potansiyel olarak zararlı bir CSS dosyasının, kullanıcının o anki URL'sinde yer alan son derece hassas bilgilere (örneğin bir oturum ID'si, şifre sıfırlama token'ı veya özel bir hash değeri) erişip buna göre stil uygulayabilmesi; kötü niyetli kişilerin "CSS Sniffing" yöntemleriyle kullanıcıların

tarayıcı geçmişini takip etmesine ve verilerini sızdırmasına olanak tanıyabilirdi ki bu, modern web güvenliği için kabul edilemez bir açıktır.

Günümüzde URL bazlı stil koşulları, güvenli olmayan CSS filtreleriyle değil; daha güvenli, kontrollü ve sunucu tarafında çalışan dinamik dillerle çözülen bir mimari desendir.

Profesyonel geliştiriciler, sunucu taraflı kodlama (PHP, Node.js, Python) veya istemci taraflı güvenli JavaScript algoritmaları kullanarak; o anki URL rotasını analiz eder ve HTML'in en üst kapsayıcısına (genellikle <body> etiketine) duruma özel bir sınıf enjekte ederler (örneğin <body class="page-blog">); CSS ise daha sonra bu güvenli ve temiz sınıfları hedefleyerek stil uygular.

@page kuralı, CSS'in sadece ekran piksellerini değil, gerçek dünya nesnelerini de yönetebildiğini gösteren; basılı çıktı (printed output) alınacağı zaman, belgenin her bir fiziksel kağıt sayfasının kenar boşluklarını (margin), kağıt boyutunu (size) ve yönünü (orientation) milimetrik hassasiyetle ayarlamasını sağlayan özel bir At-Kuralıdır.

Bu kural, web sayfasının o bildiğimiz "sürekli akan" yapısını bir kenara bırakıp, içeriği "sayfa kutusu" (page box) adı verilen dikdörtgen ve sonlu alanlara bölerek, tarayıcının yazdırma motoruna bir matbaa şablonu sunar.

Önemli bir detay olarak; bu kuralın etkileri normal ekran görünümünde asla fark edilmez, yalnızca ve sadece @media print (baskı medyası) bağlamı devreye girdiğinde veya kullanıcı "Yazdır" (Ctrl+P) komutunu verip önizleme ekranını açtığında aktifleşen bir arka plan mimarıdır.

@page kuralı, web içeriği fiziksel kağıda aktarılırken; tarayıcının kendi algoritmasıyla atadığı varsayılan kenar boşluklarını ve standart sayfa boyutlarını geçersiz kılmaya (override) yarayan bir yetki devridir.

Genellikle tarayıcılar, baskı sırasında içeriğin kenarlardan taşmasını önlemek adına muhafazakar davranıp otomatik olarak gereğinden büyük (güvenli) boşluklar bırakırlar; bu kural sayesinde kontrolü ele alıp kağıdı uçtan uca yönetebilirsiniz.

Bu ayarların temel amacı; bir finansal rapor, resmi fatura veya teknik belge gibi ciddiyet gerektiren içeriklerin, kağıt üzerinde dağınık durmasını ve taşmasını engelleyerek, okunaklı ve profesyonel bir görünümle sunulmasını sağlamaktır.

Ayrıca, tarayıcıların varsayılan olarak sayfanın tepesine ve altına eklediği, genellikle istenmeyen "URL adresi" ve "Yazdırma Tarihi" gibi bilgileri, kenar boşluklarını sıfırlayarak veya yöneterek kaldırmak da bu seviyenin kritik bir kazanımıdır.

Bu kural, genellikle @media print bloğu içinde çalıştırılır ve doğrudan kağıdın fiziksel özelliklerini hedefleyen size ve margin özelliklerini kullanır.

@media print {
  @page {
      size: A4 landscape; /* A4 Kağıt, Yatay Duruş */
      margin: 1cm;        /* Her kenardan 1cm boşluk */
  }
}

Size (Boyut ve Yön): Kağıdın uluslararası ebatlarını (A4, A5, Legal) ve duruş yönünü belirler. Örneğin geniş sütunlu bir tabloyu veya panoramik bir görsel galeriyi basarken kağıdı yatay (landscape) moda almak, içeriğin sıkışmasını önleyen en pratik çözümdür.

Margin (Güvenli Alan): Sayfanın dört bir yanındaki "ölü alanı" (yazdırılabilir alanın dışındaki beyaz boşluğu) ayarlar; bu değeri küçültmek kağıt yüzeyini daha verimli kullanmayı sağlarken, artırmak içeriğe odaklanan daha ferah bir okuma deneyimi sunar.

Bu seviye, web tarayıcısının dikeyde sonsuza giden akışkan yapısı ile fiziksel kağıdın kesintili doğası arasındaki çatışmayı yöneterek; kritik içeriklerin (örneğin bir veri tablosunun başlığı ile verilerinin veya bir görsel ile açıklamasının) basılı sayfada istenmeyen ve rastgele bir noktadan bölünmesini engelleyip, geleneksel yayıncılık standartlarına uygun profesyonel bir düzeni taklit etmeyi hedefler.

Zorunlu Kesme (break-before / break-after): Tıpkı bir kitaptaki bölümlerin daima temiz bir sayfadan başlaması gibi; h1 { break-before: page; } gibi kurallar, tarayıcıya

"Bu ana başlığı gördüğün anda, sayfanın ne kadar dolu olduğuna bakmaksızın, ne olursa olsun ondan hemen önce yeni bir sayfa başlat" talimatını vererek her bölümün başlangıcını garanti altına alır.

İçerik Koruması (page-break-inside: avoid;): Bu, raporlamada en sık başvurulan "hayat kurtarıcı" özelliktir. Bir bilgi kartının veya bütünlüklü bir div bloğunun, sayfa sonuna denk geldiğinde tam ortadan ikiye bölünmesini yasaklar.

Tarayıcı bu komutu aldığında, eğer kart mevcut sayfanın kalan boşluğuna sığmıyorsa, onu bölmek yerine bir bütün halinde bir sonraki sayfanın en tepesine taşıyarak içeriğin okunabilirliğini ve bütünlüğünü korur.

@page :left ve :right: Kitap veya dergi mizanpajını dijitale taşımak için kullanılan bu sözde sınıflar çift numaralı ve tek numaralı sayfalara

farklı ve simetrik stiller uygulamanıza olanak tanır.

Cilt payı bırakmak için sol sayfanın sağ kenar boşluğunu, sağ sayfanın ise sol kenar boşluğunu artırmak veya sayfa numaralarını her zaman sayfanın dış köşesine hizalamak bu yöntemle mümkündür.

Bu seviye, @page kuralının sunduğu en sofistike ve ileri düzey mizanpaj yeteneği olan; basılı sayfalara statik HTML içeriğinden bağımsız olarak dinamik içerik ekleme (Running Headers/Footers) mimarisini temsil eder.

Köşe Kutuları (Margin Boxes): Bu kural, sayfanın ana içerik akışının dışında kalan, kağıdın atıl durumdaki kenar boşluğu alanlarını (margin); @top-left, @bottom-center gibi isimlendirilmiş 16 farklı sanal kutuya bölerek, bu alanlarda sayfa numarası, belge başlığı veya güncel tarih gibi özel içerikleri göstermeyi sağlayan programlanabilir bir ızgara sistemi tanımlar.

Bu özelliğin en büyük devrimi otomasyondur; sayfa numaraları (content: counter(page)) veya bölüm başlıkları gibi sürekli değişen üstbilgi ve altbilgilerin (header/footer), HTML DOM yapısında manuel olarak yüzlerce kez tekrar edilmesine gerek kalmadan, CSS motoru tarafından

otomatik olarak ve her sayfanın kendi sırasına özel olarak üretilmesini sağlar.

Bu yetenek, web içeriğinin basit bir çıktı olmaktan çıkıp, numaralandırılmış ve düzenlenmiş profesyonel yayıncılık standartlarına

( kitap veya resmi rapor formatına ) yaklaşmasını mümkün kılar.

Kritik bir akademik not olarak; @page kuralının ve özellikle bu gelişmiş Köşe Kutularının tarayıcı desteği, modern ve güncel tarayıcılarda bile diğer standart CSS özelliklerine kıyasla çok daha düzensiz, parçalı ve eksiktir.

Bu nedenle profesyonel geliştiricilerin, karmaşık baskı stillerini tasarlarken bu teknik olgunluk riskini bilmesi; ve mizanpajın farklı tarayıcı motorlarında bozulmadan render edileceğinden emin olmak için çok kapsamlı fiziksel testler yapması zorunludur.