HTML5 Giriş Rehberi: Living Standard ve Semantik Yapı

HTML5, web geliştirme tarihinde sadece yeni etiketler tag ekleyen bir sürüm olmanın ötesinde, web'i pasif bir belge görüntüleme platformundan tam teşekküllü bir uygulama platformuna dönüştüren felsefi ve mimari bir kırılmayı temsil eder.

WHATWG: tarafından "Canlı Standart" olarak benimsenen HTML5, tarayıcıların gerçek hayattaki ihtiyaçlara göre sürekli güncellenmesi gerektiği fikri üzerine kurulmuştur.

HTML5'in getirdiği temel mimari değişimler, daha önce incelediğiniz "Sorumlulukların Ayrımı" ilkesini ( Separation of Concerns ) ilkesini pekiştirirken, Davranış ( JavaScript ) katmanına da muazzam güç katmıştır:

HTML5, içeriğin anlamını doğru bir şekilde iletmek için yeni etiketler ( <article>, <section>, <nav> ) sunmuştur.

Bu, daha önceki dönemde yaygın olan anlamsız <div> etiketleriyle yapılan "yapısal kaos" sorununu çözmeyi hedefler.

Semantik yapı, Erişilebilirlik ve SEO gibi kritik Nitelik Gereksinimlerini doğrudan karşılar.

HTML5, tarayıcıya sadece bir metin görüntüleyicisi değil, uygulama işlevselliği ekleyen bir dizi yerel API entegre etmiştir.

Bu API'lar ( Canvas, Web Storage, Service Workers ), JavaScript'in doğrudan tarayıcı içinde karmaşık görevleri yerine getirmesine olanak tanımıştır.

Geleneksel web standartlarının aksine, HTML5 en baştan mobil cihazlar ve dokunmatik etkileşim düşünülerek tasarlanmıştır.

Bu, modern Duyarlı Tasarım ( Responsive Design ) mimarilerinin temelini oluşturur.

HTML5'in en temel mimari katkısı, tarayıcının ve geliştiricinin içerik yapısını anlamasını sağlayan anlamsal etiketlerin zorunlu kılınmasıdır.

Bu, sadece etiket isimlerini değiştirmekten öte, Yapı katmanının temel sorumluluğunu

"içeriğin amacını ve anlamını tanımlamak" yeniden güçlendiren felsefi bir geri dönüştür.

Tarayıcı Savaşları: döneminde, geliştiriciler tüm sayfa düzenini anlamsız etiketler ve CSS sınıflarıyla inşa etmek zorundaydı.

<div> etiketleri ve CSS sınıflarıyla <div class="header">, <div class="footer"> inşa etmek zorundaydı.

Bu, ortaya çıkan kodun anlamsal açıdan fakir, yönetimi zor ve karmaşık olmasına neden oluyordu "div çorbası"".

HTML5, bu yapısal kaosu çözmek için yeni anlamsal etiketleri sundu:

Yeni Etiketler: HTML5 dilin içerisine yeni etiketler geldi bunlar aşağıda sıralanmaktadır:

<header>, <nav>, <main>, <section>, <article>, <footer>.

Mimari Rolü: Bu etiketler, bir web belgesinin "mantıksal iskeletini" açıkça tanımlar.

Örneğin: Bir <article> etiketi, tarayıcıya bunun kendiliğinden anlam ifade eden, bağımsız bir içerik bloğu olduğunu söyler.

Bu net ayrım, Yapı ve Görünüm arasındaki "Sorumlulukların Ayrımı" ilkesini pekiştirir.

Anlamsal yapının mimari açıdan en kritik etkisi, iki hayati Nitelik Gereksinimi (AQC) ile doğrudan ilişkilidir:

Anlamsal etiketler, ekran okuyucular screen readers gibi yardımcı teknolojiler için hayati öneme sahiptir.

<nav> veya <header> gibi etiketler, bu cihazlara içeriğin amacını gezinme menüsü, sayfa başlığı doğrudan ileterek,

engelli kullanıcıların uygulamayı tutarlı bir şekilde kullanabilmesini sağlar.

Arama motorları Google, Bing içeriği tararken, içeriğin hiyerarşisini ve amacını anlamak için anlamsal etiketleri kullanır.

Doğru kullanılan <article> ve <h1> gibi etiketler, motorlara sayfanın ana konusu hakkında net sinyaller göndererek içeriğin daha doğru indekslenmesine yardımcı olur.

Bu yaklaşım, Tek Sorumluluk Prensibi ( SRP )'nin HTML katmanında tam olarak uygulanmasını sağlar:

HTML sadece içeriği tanımlar; nasıl görüneceği sorumluluğu ise tamamen CSS'e aittir.

Bu, geliştirme ekiplerinin kod tabanını daha temiz ve daha kolay yönetmesini sağlar.

HTML5'in ikinci büyük mimari katkısı, tarayıcıya entegre edilen yeni nesil yerel API'lar aracılığıyla, Davranış katmanının gücünü radikal bir şekilde artırmaktır.

Bu yenilikler, tarayıcıyı artık sadece bir web belgesi görüntüleyicisi olmaktan çıkarıp, karmaşık tek sayfa uygulamalarını SPA ve

çevrimdışı işlevselliği destekleyebilen tam teşekküllü bir "uygulama motoruna" dönüştürmüştür.

Bu API'ların ortaya çıkışı, mimari sorumlulukları sunucudan istemciye doğru kaydırmıştır.

Bu sayede, performans, depolama ve etkileşim gibi konulardaki yük, yerel cihazın işlem gücüne devredilmiş ve sunucuya olan bağımlılık azalmıştır.

Bu, uygulamaların daha hızlı ve kullanıcı deneyiminin daha akıcı olmasını sağlamıştır.

Yeni Yetenekler: JavaScript, bu API'lar sayesinde ilk kez yerel depolama, gelişmiş grafik çizimi, konum bilgisi edinme ve

kalıcı iki yönlü ağ iletişimi gibi "masaüstü uygulamalarına özgü" işlevleri doğrudan tarayıcı içinde gerçekleştirebilir hale gelmiştir.

Mimari Etki: Bu durum, geliştiricilerin modülerlik ve SRP: Tek Sorumluluk Prensibi ilkelerini uygulayarak uygulamalarını

"API'lar etrafında" yeniden tasarlamalarını gerektirmiştir.

Örneğin: Sunucudan gelen her veri için DOM'u manuel olarak değiştirmek yerine, Web Sockets API'ı ile gerçek zamanlı real-time ve asenkron veri akışı mimarileri kurulabilir hale gelmiştir.

HTML5, tarayıcıyı kalıcı veri depolama ve ağ trafiği yönetimi konusunda yetkilendirerek, uygulamaların performansını ve kullanılabilirliğini kökten değiştirmiştir.

Bu yetenekler, Davranış katmanının artık sunucuya bağımlı olmadan çalışabilmesini sağlayan temel mimari araçlardır.

Bu mimari atılımın felsefi temeli, web uygulamalarını "ağa bağlı olma zorunluluğundan" kurtarmaktır.

Geleneksel web mimarisinde, her durum değişikliği, her sayfa yeniden yüklemesi veya her kritik veri talebi için sunucuya gitmek zorunluydu.

HTML5'in bu araçları ( Web Storage ve Service Workers ), uygulama durumunun ve varlıkların yönetimi sorumluluğunu yerel cihaza kaydırarak bu zorunluluğu ortadan kaldırdı.

Bu, JavaScript için büyük bir güçlenmedir; artık JavaScript, yerleşik depolama mekanizmaları aracılığıyla uygulamanın "kalıcı durumunu" yönetebilir ve Service Workers ile de ağ iletişimini bir vekil ( proxy ) gibi kontrol edebilir.

Sonuç olarak, web uygulamaları daha hızlı yanıt süresine ( azalan ağ gecikmesi sayesinde ) ve kesintisiz hizmet

( çevrimdışı yetenek ) garantisine kavuşmuştur.

Web Storage, bir uygulamanın veriyi kullanıcı cihazında, büyük ve kalıcı olarak depolamasını sağlayan bir API setidir.

Bu özellik, önceki dönemlerde kullanılan, boyutu çok sınırlı olan ve her HTTP isteğiyle sunucuya gönderilen "çerezlerin" yarattığı ağ yükü ve performans sorunlarını çözmek için mimari bir zorunluluktan doğmuştur.

Bu depolama mekanizmasının temel mimari avantajı, "sorumluluğun ayrılması ilkesini" desteklemesidir.

Kullanıcı tercihi veya uygulama yapılandırması gibi sıkça erişilen veriler, ana sunucu trafiğine dahil edilmek yerine, yerel olarak yönetilir.

Cookies (Çerezler), her HTTP isteğiyle otomatik olarak sunucuya gönderilirken ( bu da güvenlik zafiyetlerine - özellikle CSRF'ye - yol açabilir ),

Web Storage sadece JavaScript kodu aracılığıyla erişilebilir.

Bu, geliştiriciye "veri yönetimi" üzerinde daha fazla kontrol ve izolasyon sağlar.

Ayrıca, çerezlerin 4 KB olan depolama sınırının aksine, Web Storage genellikle 5 MB ile 10 MB arasında veri tutabilir.

Bu büyük kapasite, statik varlıkların veya sık kullanılan API yanıtlarının yerel olarak cachelenmesini mümkün kılar.

Verilerin client tarafında tutulması, her veri ihtiyacında sunucuya gitme gereksinimini ortadan kaldırır.

Bu durum, "ağ gecikmesini" azaltır ve uygulamanın yanıt süresini anında iyileştirir.

Sonuç olarak, uygulama daha hızlı yüklenir, daha akıcı bir kullanıcı deneyimi sunar ve sunucu/ağ trafiği üzerindeki yükü hafifleterek sistemin genel ölçeklenebilirliğine katkıda bulunur.

Web Storage, modern Tek Sayfa Uygulamaları'nın hızlı durum yönetiminin temel dayanağıdır.

Service Workers, HTML5'in en büyük mimari atılımıdır.

Bunlar, tarayıcı ile ağ arasında çalışan, JavaScript ile yazılmış bir proxy görevi görürler.

Service Worker'lar, web sayfaları kapatıldıktan sonra bile arka planda çalışabilir ve ağ trafiğini programlı olarak

yönetme yeteneği sunar.

Service Worker'lar, gelen ağ isteklerini yakalar ve Cache API'ı kullanarak bu isteklerin yanıtlarını önbellekten döndürebilirler.

Bu, uygulamaların "tamamen çevrimdışı" çalışmasını sağlar ve Kullanılabilirlik AQC'sini dramatik bir şekilde artırır.

Uygulama kapalı olsa bile push bildirimlerini alabilir veya arka plan senkronizasyonu yapabilirler.

Bu, web uygulamalarının geleneksel mobil uygulamalarla rekabet edebilecek yetenekler kazanmasını sağlamıştır ve bu PWA mimarisinin temelini oluşturur.

Service Worker'lar, ağ bağlantısı zayıf olduğunda bile hızlı yükleme süreleri sağlayarak Dayanıklılığı artırır.

Ağdan veri gelmezse, önbellekteki veriyi sunarak uygulamanın "asla bozulmamasını" garanti etmeye yardımcı olur.

HTML5'in Davranış katmanına kattığı en belirgin güç, tarayıcıda grafik ve medya içeriğini yerel olarak yönetme yeteneğidir.

Bu, önceki dönemlerde Flash ve Java Applet'ler gibi harici, ikili eklentilere olan bağımlılığı ortadan kaldıran ve mimariyi kökten basitleştiren bir atılımdır.

Eklenti bağımlılığının sona ermesi, sistemin "güvenliğini, erişilebilirliğini ve performansını" doğrudan artırmıştır.

Bu atılım, web mimarisinde görsel sunum sorumluluğunu eklentilerden alıp, tamamen standartlaştırılmış, açık kaynaklı ve JavaScript ile kontrol edilebilir bir alana taşıdı.

Artık JavaScript, DOM'u manipüle etmenin ötesine geçerek, piksel düzeyinde çizim yapabilir, matematiksel olarak

ölçeklenebilir vektörler oluşturabilir ( SVG ) ve medya oynatımının yaşam döngüsünü tam olarak yönetebilir.

Bu, web'i gelişmiş veri görselleştirme, 2D/3D oyun geliştirme ve yüksek kaliteli medya tüketimi için güvenilir, platformlar arası bir platform haline getiren temel mimari dönüm noktasıdır.

Canvas API, JavaScript'e piksel düzeyinde çizim yapma yeteneği veren, iki boyutlu ve üç boyutlu bir çizim yüzeyidir.

Bu, tarayıcının yerel grafik donanımına ( (GPU) ) erişim sağlayan bir kapı görevi görür.

Canvas, tamamen JavaScript tarafından kontrol edilen bir tuvaldir.

HTML'de sadece tek bir <canvas> etiketi olarak yer alır, ancak bu etiketin içindeki tüm çizimler , şekiller ve animasyonlar JavaScript komutlarıyla yönetilir.

Bu mimari, grafik mantığını Oyun motorları , veri görselleştirme HTML'in yapısından tamamen ayırarak Sorumlulukların Ayrımı ilkesini destekler.

Canvas'ın yüksek performansının ardındaki mimari sır, "Anında Modda Görüntüleme" kullanmasıdır.

İşleyiş: Canvas, çizim komutlarını ( fillRect , drawLine ) anında yürütür ve bir sahne grafiği saklamaz.

Bir sonraki kare çizildiğinde, önceki kare tamamen silinir ve yeniden çizilir.

Avantajı: Yüksek kare hızına ve karmaşık dinamik görünümlere ihtiyaç duyan uygulamalar için temel araçtır.

GPU hızlandırmasını doğrudan kullanabildiği için Performans AQC'sini maksimum düzeyde karşılar.

Canvas, piksel tabanlı olduğu için, yapısal anlamı ve DOM'un sağladığı kolay erişilebilirliği feda eder.

Canvas içinde çizilen bir buton, DOM için bir buton değil, sadece bir piksel kümesidir.

Bu durum, karmaşık UI'larda Erişilebilirlik sorunları yaratabilir ve geliştiricinin bu durumu JavaScript ile manuel olarak ele almasını gerektirir.

Bu, Canvas'ın güçlü ancak dikkatli kullanılması gereken bir araç olduğunu gösteren önemli bir mimari kısıtlamadır.

SVG, XML tabanlı bir işaretleme dilidir ve grafikleri matematiksel vektörler yol , eğri , nokta kullanarak tanımlar.

SVG, HTML5'in Yapı katmanına görsel öğeleri sadece göstermekle kalmayıp, onlara anlamsal anlam yükleme yeteneği veren kritik bir katkıdır.

SVG'nin mimari başarısının temelinde, "Tutulan Modda Görüntüleme" mekanizması yatar.

DOM Entegrasyonu: Canvas'ın piksel tabanlı matrisinin aksine, SVG içindeki her şekil, çizgi ve metin, tarayıcının "Belge Nesne Modeli" ağacında ayrı bir düğüm olarak yer alır.

Bu, SVG'nin manipüle edilebilir bir veri yapısı olduğu anlamına gelir.

JavaScript , DOM'un standart seçici metotlarını getElementById, querySelector kullanarak SVG içindeki herhangi bir öğeyi kolayca seçebilir, stilini değiştirebilir ve etkileşim event ekleyebilir.

Bu, Bakım Kolaylığı artırır, çünkü bir grafiğin tümünü yeniden çizmeye gerek kalmadan sadece ilgili parçayı güncelleyebilirsiniz.

SVG, yapı katmanına sağladığı şeffaflık sayesinde kritik AQC'leri doğrudan destekler.

Vektör tabanlı olduğu için çözünürlükten tamamen bağımsızdır.

Bir SVG grafiği, küçük bir mobil ekranda veya dev bir 4K monitörde "kalite kaybı olmadan" matematiksel olarak ölçeklenir.

Bu, modern Duyarlı Tasarım mimarileri için hayati bir gereksinimdir.

Grafik, metin tabanlı XML formatında olduğu için, içinde bulunan metinler ve elementler

arama motorları ve ekran okuyucular tarafından okunabilir ve indekslenebilir.

Bu, Canvas'ta eksik olan "anlamsal değeri" sisteme geri kazandırır.

SVG öğeleri, harici CSS dosyaları kullanılarak stilize edilebilir.

Bu, Yapı ve Görünüm sorumluluğunun temiz bir şekilde ayrılmasını sağlar.

Bu özellikler, SVG'yi statik logolar, haritalar ve veri grafikleri gibi yapısal bütünlüğün ve ölçeklenebilirliğin önemli olduğu yerlerde Canvas'a karşı daha üstün bir mimari seçim haline getirir.

Bu etiketlerin en önemli mimari katkısı, Sorumlulukların Ayrımı ilkesini pekiştirmesidir:

HTML5'in getirdiği <video> ve <audio> etiketleri, web mimarisini, multimedya içeriği açısından harici eklenti bağımlılığından ( QuickTime , Flash Player gibi ) tamamen kurtaran devrimci bir adımdır.

Bu, sadece bir özellik eklemek değil, sistemin güvenlik, performans ve bakım AQC'lerini iyileştiren köklü bir yapısal değişimdir.

Yapı (HTML): HTML sadece medyanın varlığını ve temel kaynağını ( <video src="..."> ) tanımlar.

Oynatma mantığı ve kontrolü (play(), pause(), seek(), volume gibi metotlar) tamamen JavaScript ile sağlanır.

Geliştiriciler, medya akışını duruma bağlı olarak dinamik bir şekilde yönetebilir ve özel oynatıcı arayüzleri oluşturabilirler.

Bu ayrım, medya işleme katmanını, uygulamamızın ana "Davranış" mantığına entegre etme esnekliği sunar.

Harici eklentilerin sona ermesi, sistemdeki en büyük güvenlik risklerinden birini ortadan kaldırmıştır.

Eklentiler genellikle ayrıcalıklı erişime sahip ikili kodlardır ve düzenli olarak güvenlik açıkları barındırırlar.

"Eklentisiz çalışma", bu tür güvenlik zafiyetlerinin ve geliştiricinin platformlar arası uyumluluk için harcadığı bakım yükünün önüne geçer.

Medya çözme ( decoding ) işleminin tarayıcının yerel kodunda ve donanımında çalışması, eklenti tabanlı işleme göre çok daha hızlı ve verimlidir.

Bu, daha akıcı oynatma ve daha az işlemci kullanımı anlamına gelerek Performans AQC'sini doğrudan artırır.

Yerel HTML etiketleri, varsayılan olarak tarayıcıların ve işletim sistemlerinin erişilebilirlik özellikleriyle ( altyazı, klavye navigasyonu ) uyumludur.

Bu, harici eklentilerin çoğu zaman sunamadığı bir Erişilebilirlik AQC'si garantisi sunar.

HTML5'in Davranış ( JavaScript ) katmanına kazandırdığı bu API grubu, web uygulamaları'nın çevresiyle etkileşimini kökten değiştirmiştir.

Bu yenilikler, web'i sadece içerik sunan bir araç olmaktan çıkarıp, "gerçek zamanlı", etkileşimli ve bağlama duyarlı context-aware bir platforma dönüştüren son mimari adımlardır.

Bu API'ların felsefi temeli, geleneksel "İstek-Yanıt"döngüsünün sınırlamalarını aşmaktır.

Önceki mimaride, sunucudan sürekli güncellemeler almak için istemci sürekli olarak sunucuyu yoklamak zorundaydı.

Bu, hem sunucu yükünü artırıyor hem de ağ gecikmesini yükselterek performansı düşürüyordu.

WebSockets ile tarayıcı, sunucu ile "kalıcı ve iki yönlü" bir bağlantı kurarak bu yoklama sorununu çözer.

Bu, gerçek zamanlı sohbet uygulamaları, canlı spor skorları ve çok oyunculu oyunlar gibi anında etkileşim gerektiren mimarilerin önünü açmıştır.

Geolocation API ise, uygulamanın kullanıcının fiziksel konumu gibi "çevresel bağlam verilerine" JavaScript aracılığıyla güvenli bir şekilde erişmesini sağlar.

Bu, konum tabanlı hizmetler ve haritalama uygulamaları için Davranış katmanını güçlendirir.

Bu API'lar, uygulamaların sadece veriyi değil, aynı zamanda "zamanı ve mekanı" da yönetebilme yeteneğini JavaScript'e devrederek, mobil ve masaüstü uygulama mimarilerine rakip olabilecek bir esneklik sunar.

WebSockets'in ortaya çıkışı, önceki dönemlerde sunucudan güncel veri almak için kullanılan verimsiz HTTP yoklama tekniklerine

mimari bir çözümdür.

WebSockets, modern web mimarisinde "gerçek zamanlı" ve "eşzamanlı" uygulamaların geliştirilmesini sağlayan en önemli ağ protokolü atılımıdır.

Geleneksel HTTP'nin sınırlamalarını aşarak, Davranış katmanına sunucu ile "kalıcı", "iki yönlü" bir iletişim kanalı kurma yeteneği verir.

Geleneksel HTTP/1.1, her istek için yeni bir bağlantı açıp kapatma yükü taşır ve her mesajda gereksiz büyük başlık bilgisi header overhead gönderir.

Maliyet: Sürekli yoklama, bu başlıkların tekrar tekrar gönderilmesi nedeniyle ağ gecikmesini ve sunucudaki kaynak tüketimini aşırı artırıyordu.

Bu durum, yüksek "Performans" ve düşük "Maliyet" AQC hedeflerine ulaşmayı engelliyordu.

WebSockets, tek bir TCP bağlantısı üzerinden hem istemciden sunucuya hem de sunucudan istemciye veri göndermeye olanak tanıyan kalıcı bir kanal kurar.

Protokol Yükseltme: İletişim, HTTP üzerinden başlayan basit bir el sıkışma ile başlar, ancak bu başarılı olduğunda bağlantı, kalıcı bir WebSocket protokolüne yükseltilir.

Minimal Yük: Kurulan bu kalıcı kanalda, veri gönderimi, HTTP başlıklarının aksine son derece hafif mesaj çerçeveleri ile yapılır ve bu, ağ trafiği yükünü dramatik bir şekilde düşürür.

WebSockets'ın mimariye en büyük etkisi, Davranış katmanını anlık tepki verebilecek şekilde güçlendirmesi ve Sunucu İtme yeteneği kazandırmasıdır. ( Server Push )

Asenkron İletişim: WebSockets, doğal olarak Olay Güdümlü Mimari desenini destekler.

Sunucu, bir olay gerçekleştiğinde veriyi istemciye iterek gönderir; istemci sürekli yoklama yapmak zorunda kalmaz.

Düşük Gecikme: Kalıcı kanal sayesinde, mesajlar milisaniyeler içinde iletilir.

Bu, canlı veri yayınları ve anında sohbet sistemleri gibi düşük gecikmeli sistemler için hayati öneme sahiptir.

Güvenlik (WSS): WebSockets, güvenli iletişim için WSS protokolünü kullanır, bu da Gizlilik AQC'sini sağlar.

Geolocation API, web uygulamalarının kullanıcının fiziksel konum verilerine coğrafi enlem ve boylam JavaScript aracılığıyla güvenli bir şekilde erişmesini sağlayan bir standarttır.

Önceki web mimarilerinde konum bilgisine erişim, üçüncü taraf eklentiler veya karmaşık sunucu tarafı IP tabanlı tahminler gerektirirken, Geolocation API bu işlevi tarayıcıya yerel olarak entegre etmiştir.

Bu API'nın mimari rolü, uygulamayı "bağlama duyarlı" hale getirmektir.

Yerel İşlem Gücü: Konum bilgisi, JavaScript tarafından doğrudan cihazın GPS , Wi-Fi veya hücresel ağ verileri kullanılarak alınır.

Bu, sunucunun konum tahmin yükünü ortadan kaldırarak Performans ve Ölçeklenebilirlik AQC'lerine katkıda bulunur.

Davranışsal Kontrol: JavaScript, kullanıcının konumunu anlık olarak takip edebilir ( watchPosition ) veya tek bir istekte bulunabilir ( getCurrentPosition ).

Bu, uygulamaların "konum bazlı dinamik işlevler" geliştirmesine olanak tanır.

Güvenlik: Geolocation API, kullanıcı gizliliğini ön planda tutan bir güvenlik modeli uygular.

Tarayıcı, konum bilgisine erişimden önce mutlaka kullanıcı izni ister ve API, yalnızca güvenli bağlantılar üzerinden erişilebilir ve bu,

Güvenlik AQC'sinin temel bir gerekliliğidir.

Geolocation API, JavaScript'in sadece sanal değil, aynı zamanda "fiziksel dünya ile de etkileşime girmesini" sağlayan, modern ve kişiselleştirilmiş web deneyimlerinin temelini atmıştır.

HTML, içeriğe anlam semantik verir burada bir metin parçasının basit bir metin mi, yoksa sayfanın ana başlığı mı olduğunu belirtmek için kullanılır.

Web sayfaları, devasa bir binanın farklı katları gibidir; her katın kendine özgü bir yapısı ve amacı vardır.

HTML, bu yapıyı oluşturan, yani bir web sayfasının iskeletini kuran temel dildir.

Bir web sayfasının içeriğini metinler, görseller, videolar ve bu içeriğin düzenini başlıklar, paragraflar, listeler tanımlamak için kullanılır.

HTML, etiketler tag adı verilen anahtar kelimelerden oluşur.

Çoğu etiket, içeriği sarmalayan bir açılış etiketi ( <etiketadi> ) ve bir kapanış etiketi ( </etiketadi> ) şeklinde çiftler halinde kullanılır.

Bu etiketlerin içine ek özellikler genişlik, kaynak adresi gibi tanımlayan nitelikler attribute eklenir.

HTML, tarayıcılara o sayfanın ne olduğunu ve içeriği nasıl göstermesi gerektiğini söyler.

Tek başına HTML, basit ve biçimlendirilmemiş bir metin gösterir.

Bir web sayfası genellikle "üç ana dille" inşa edilir:

İnternet, modern dünyanın vazgeçilmez bir parçası haline gelmiş olup, bu devasa bilgi ağının temel yapı taşlarından biri de HTML'dir.

"HyperText Markup Language" kısaltması olan HTML, web sayfalarının "içeriğini ve yapısını" tanımlamak için kullanılan bir işaretleme dilidir.

Web'in temellerini oluşturan Yapı ( HTML ), Görünüm ( CSS ) ve Davranış ( JavaScript ), bir yazılım mimarisinin en temel düzeyde uygulaması gereken "Sorumlulukların Ayrımı" ilkesinin en saf halidir.

Bu üç temel taş, bir projenin büyüklüğünden, kullanılan dilden veya mimari desenden bağımsız olarak, web üzerindeki her uygulamanın bütünlüğünü ve kalitesini belirler.

Bu üçlünün ayrılması, sadece estetik bir tercih değil, aynı zamanda zorunlu bir "mühendislik disiplinidir" ve mimari kararların temelini oluşturur:

Yapı (HTML) [Ne Var?]: Verinin içeriğini, iskeletini ve anlamsal düzenini belirler ve tamamen içeriğe ve anlama odaklanır.

Görünüm (CSS) [Nasıl Görünüyor?]: Yapının kullanıcıya nasıl sunulacağını, stilini ve görsel yerleşimini içeriği veya etkileşimi değiştirmemelidir. belirler.

Davranış (JavaScript) [Nasıl Çalışıyor?]: Kullanıcı etkileşimine tepki veren, veriyi işleyen, sunucudan veri getiren ve DOM'u dinamik olarak manipüle eden etkileşim ve "iş mantığı"'nı yönetir.

Bu katı ayrım, uygulamanın Bakım Kolaylığı'nı artırır; çünkü stilin değişmesi asla temel iş mantığını veya içeriği bozmamalıdır.

Ayrıca, Erişilebilirlik ve SEO gibi kritik nitelik gereksinimlerini de doğrudan destekler.

Modern JavaScript çatılarının React, Vue ortaya çıkışıyla birlikte, bu üç unsur teknik olarak "bileşen" adı altında aynı dosya içinde yeniden birleşmiş gibi görünse de, bu bir felsefi çakışma değil, kapsülleme ve SRP'nin bir uygulamasıdır.

Bileşenler, görünüm, yapı ve davranışın ilgili olduğu tek bir sorumluluğu bir UserCard gibi bir bileşen kendi içlerinde izole ederler.

Mimari Desenler ve Prensipler çalışmanızın temel amacı da budur:

Bu üç temel taşı, büyük sistemlerde dahi birbirine bağımlı ancak gevşek bağlı tutmanın en iyi yöntemlerini anlamak ve uygulamaktır.

CSS Metodolojileri, stil kodunu yazma ve organize etme sürecine yapısal disiplin getiren, kural setleridir.

Saf CSS'in en büyük sorunu olan "Global Kapsam" nedeniyle oluşan isim çakışmalarını ve kod tekrarını çözmek amacıyla ortaya çıkmışlardır.

Bu metodolojiler, bir yazılım mimarının "Yüksek Uyum" ve "Gevşek Bağlılık" prensiplerini CSS düzeyine taşımasının yoludur.

BEM ( Block , Element , Modifier ), bu metodolojilerin en popüleridir.

BEM, her CSS sınıfının bir Blok ( bağımsız bileşen ), bu bloğa ait bir Element (bloğun parçası ) veya bloğun değişik bir durumu olduğunu net bir şekilde tanımlayan bir adlandırma standardı sunar.

Bu katı adlandırma kuralı, her stilin ne yaptığını ve nereye ait olduğunu ( Tek Sorumluluk Prensibi'ne benzer şekilde) kesin olarak izole eder.

Bu sayede, stil kodunuz bir "mimari yapı" kazanır ve binlerce satıra ulaşsa bile yönetilebilir kalır.

CSS Ön İşlemcileri, temel CSS diline "programlama yetenekleri" ekleyerek stil geliştirme sürecini dönüştüren araçlardır.

Tarayıcılar bu kodları doğrudan anlayamadığı için, ön işlemciler kodunuzu Sass , Less alıp derleyerek compile standart CSS çıktısına dönüştürürler.

Bu yaklaşımın temel felsefesi, büyük ölçekli projelerde CSS'in barındırdığı tekrarı redundancy azaltmaktır.

Ön işlemciler sayesinde, bir mimar şunları başarabilir:

Değişkenler (Variables): Proje genelinde kullanılan renkler , yazı tipleri , boşluk değerleri gibi değerlerin merkezi olarak yönetilmesini sağlar. ( DRY Prensibine birebir uyum).

İç İçe Yerleştirme (Nesting): CSS seçicilerinin DOM yapısını taklit ederek iç içe yazılmasına olanak tanır, bu da okunaklılığı artırır.

Mixin ve Fonksiyonlar: Tekrar eden stil bloklarının ( border-radius için tüm tarayıcı önekleri ) tek bir yerden çağrılabilen fonksiyonlar halinde kapsüllenmesini sağlar.

Bu, kodun "yeniden kullanılabilirliğini" artırır.

Ön işlemciler, temel CSS dosya yapısının modülerliğine" ve yönetim kolaylığına odaklanarak, mimariyi daha esnek ve verimli hale getirir.

Modüler CSS Yaklaşımları stil sorununu global bir sorun olmaktan çıkarıp, bileşen düzeyinde "yerel bir sorun" haline getiren modern mimari paradigmaları temsil eder.

Bu yaklaşımların doğuşu, özellikle Bileşen Tabanlı Mimari ve Tek Yönlü Veri Akışı felsefelerinin yükselişiyle hızlanmıştır.

Bu yaklaşım, JavaScript'in gücünü kullanarak stil kodunu doğrudan JavaScript bileşen dosyalarının içine yerleştirir.

En kritik avantajı, her bileşenin stilini otomatik olarak eşsiz unique bir sınıf adıyla scoped CSS kapsülleyerek, isim çakışması sorununu kökten çözmesidir.

Stil artık durum state ve JavaScript mantığı ile tamamen entegre ve dinamiktir'tir.

Bu yaklaşım ise, önceden tanımlanmış küçük, tek amaçlı yardımcı sınıfların doğrudan HTML'de kullanılmasını önerir

( flex , pt-4 , text-center ).

Bu, stil mantığını merkezi CSS dosyalarından alıp doğrudan sunum ( View ) katmanına taşır ve geliştirme hızını ( dramatically ) artırır.

Bu dönem ( 1995–2000 ), web'in pasif bir belgeden aktif bir platforma dönüştüğü kritik bir geçiş sürecini temsil eder.

Web'i ticari ve halka açık hale getiren bu süreç, temelinde Yapı dilinin görev sınırlarını belirleme mücadelesini barındırıyordu.

HTML 2.0 ile ilk resmi standartlar konmuş olsa da, Tarayıcı Savaşları adı verilen rekabetçi ortam, Netscape ve

Internet Explorer gibi tarayıcı üreticilerinin standardı görmezden gelerek kendi özel etiketlerini ( stil nitelikleri gibi ) sisteme zorla enjekte etmesine neden oldu.

Bu durum, mimari açıdan kabul edilemez bir karmaşayı beraberinde getirdi:

HTML, içeriği ve yapıyı tanımlama ana sorumluluğunu bırakıp, görünüm sorumluluğunu üstlenmeye başladı.

Geliştiriciler, bir metni ortalamak veya rengini değiştirmek için HTML etiketlerini kullandıkça, kodun bakım kolaylığı ve erişilebilirliği ciddi şekilde düştü.

Bu yapısal ihlal, web mimarlarını, içeriği stilinden kesinlikle ayırmak ve uyumluluğu sağlamak için daha katı çözümler

( CSS'in zorunlu kılınması ve XHTML ) aramaya zorlayan temel itici güç oldu.

Bu dönemi incelemek, modern front-end mimarisinin neden katı bir Sorumluluk Ayrımı talep ettiğini anlamak için hayati önem taşır.

1995 yılında IETF tarafından yayınlanan HTML 2.0, web tarihinin ilk gerçek resmi standardı olarak kabul edilir.

Bu sürüm, Tim Berners-Lee'nin ilk taslaklarından gelen dağınık özellikleri bir araya getirerek, form yapıları ve temel

etkileşim özelliklerini tanımlayan ilk disiplinli belgedir.

HTML 2.0'ın mimari açıdan en önemli başarısı, platform bağımsızlığı ilkesini kağıda dökmesidir; bu sayede aynı HTML kodunun farklı işletim sistemlerinde tutarlı bir şekilde çalışmasının yolu açılmıştır.

Kullanıcı girdilerini sunucuya taşımayı sağlayan <form> yapısı bu sürümle standartlaşmış, web belgesi olmaktan çıkıp veri odaklı bir

uygulama katmanına evrilmeye başlamıştır.

Ancak henüz CSS mevcut olmadığı için, yapısal etiketler ( H1, P vb. ) doğrudan görsel sunumla ilişkilendirilmiş, bu da daha sonraki yıllarda yaşanacak "yapı-stil karmaşasının" ilk tohumlarını atmıştır.

HTML 2.0, kaotik bir büyüme sürecinden mühendislik disiplinine geçişin ilk köprüsüdür ve modern web'in temel iskeletini oluşturur.

HTML 3.2, tarafından yayımlanan ilk resmi sürüm olmasına rağmen, mimari açıdan en disiplinsiz ve kaotik dönemi temsil eder.

Bu dönem, Tarayıcı Savaşları adı verilen yoğun rekabet ortamının zirvesiydi ve standardizasyon çabaları, ticari baskılar karşısında zorlanıyordu.

Bu dönemin temel mimari sorunu, tarayıcı üreticilerinin ( Netscape ve Microsoft) pazar payı kazanmak için standarda uygun olmayan etiketleri ve nitelikleri sisteme eklemesiyle başladı.

HTML'in Kötüye Kullanımı: Geliştiriciler, sitelerini görsel olarak biçimlendirmek için mecburen HTML etiketlerini amacının dışında kullanmaya başladılar.

Örneğin: Sayfa düzeni tamamen <table> etiketleri ile inşa ediliyor, metin stili ise <font>, bgcolor ve align gibi görünüm tabanlı niteliklerle belirleniyordu.

Anlamsal Felaket: HTML, içeriğin anlamını tanımlama birincil görevini bırakıp, nasıl görüneceğini tanımlamaya odaklandı.

Bu, hem erişilebilirliği hem de arama motorları için içeriğin anlaşılırlığını yok etti.

Bu rekabetçi ortam, web mimarisi için büyük bir uyumluluk karmaşası yarattı:

Çatallı Kodlama (Forked Code): Geliştiriciler, sitenin her iki ana tarayıcıda da aynı görünmesi için sıkça koşullu kod yazmak zorundaydı.

Bu durum, kodun bakım maliyetini katlanarak artırdı ve DRY prensibini ihlal etti.

Muazzam Teknik Borç:Bir projenin yüzlerce sayfa içerdiği düşünüldüğünde, ( sadece site genelindeki yazı tipini değiştirmek için ) her HTML dosyasının tek tek düzenlenmesi gerekiyordu.

Bu yapısal ihlal, web uygulamalarının Bakım Kolaylığı ( Maintainability ) sıfıra indiren bir krizdi.

HTML 3.2'deki bu yapısal felaket, W3C'yi Yapı ve Görünümü kesin olarak ayırmaya itti.

Bu zorluklar, "Basamaklı Stil Sayfaları" ( CSS ) standardının hızla benimsenmesini zorunlu kılan mimari itici güç oldu.

Amaç, stili >HTML'den tamamen çıkarıp ayrı bir katmana CSS dosyalarına taşımaktı.

Bu, Sorumlulukların Ayrımı ilkesinin mimari düzeyde yeniden tesis edilme çabasıydı.

HTML 4.01, web mimarisi tarihinde bir dönüm noktasıdır çünkü W3C'nin Yapı ve Görünüm sorumluluklarını birbirinden kesin olarak ayırma çabalarının "nihai ve başarılı standardizasyonunu" temsil eder.

Bu sürümün temel felsefesi, Tarayıcı Savaşları döneminde ihlal edilen Sorumlulukların Ayrımı ilkesini zorunlu kılmaktı.

HTML, tamamen içeriğin anlamsal yapısına odaklanmalı; tüm stil ve düzen işleri ise harici CSS dosyalarına devredilmeliydi.

HTML 4.01, <font>, bgcolor, align gibi doğrudan görsel sunumla ilgili tüm nitelikleri ve etiketleri resmen kullanımdan kaldırdı.

Bu, geliştiricilere "CSS kullanmanın zorunlu olduğunu" bildiren açık bir mimari talimattı.

Erişilebilirlik (Accessibility) Vurgusu: Stil etiketlerinin kaldırılması, içeriğin anlamının cihazdan bağımsız olarak anlaşılmasını sağladı ve Erişilebilirlik AQC'sini ciddi ölçüde iyileştirdi.

CSS Zorunluluğu: HTML 4.01, web mimarisini "HTML + CSS + JavaScript" üçlüsünün üzerine kurarak, Yapı, Görünüm ve Davranış arasındaki modern sorumluluk ayrımını tam anlamıyla tesis eden son standart olmuştur.

XHTML (Extensible HyperText Markup Language), HTML 4.01'den sonra W3C'nin yayımladığı bir dizi spesifikasyondur.

Temel amacı, HTML'i XML kurallarına uygun hale getirerek web belgelerine daha katı bir "yapısal saflık" ve "tutarlılık" kazandırmaktı.

XHTML'in temel felsefesi, Tarayıcı Savaşları dönemindeki yapısal karmaşayı ortadan kaldırarak, web içeriğinin

"makine tarafından daha kolay işlenebilir" olmasını sağlamaktı.

Bu, gelecekteki web teknolojilerinin ( SVG , MathML ) HTML ile kolayca birleşmesini sağlayacak ideal bir mimari zemin hazırlama girişimiydi.

XHTML, HTML'in esnek sözdiziminin aksine, katı kuralları zorunlu kıldı:

Tüm etiketler küçük harfle yazılmalıdır.

Tüm tekli etiketler kapanmalıdır (<br> yerine <br />).

Tüm nitelikler tırnak işaretleri içinde olmalıdır.

Mimari Sonuç: Bu katılık, geliştirme sürecinde "hataları erken yakalamayı" kolaylaştırdı.

Ancak, bu katı kurallara uymayan sayfaları tarayıcıların göstermeyi reddetmesi nedeniyle, web'in esnek yapısına uygun olmadığı anlaşıldı.

XHTML, kağıt üzerinde mimari saflığı hedeflerken, geliştiriciler ve tarayıcı üreticileri için çok fazla pratik zorluk yarattı.

XHTML'in katı kurallara odaklanması, web'in yeni gereksinimlerini ( Video , mobil uygulamalar, Canvas ) görmezden geliyordu.

Bu durum, tarayıcı üreticilerinin W3C'den ayrılarak WHATWG grubunu kurmasına yol açtı.

WHATWG, "Standartlar Tarayıcıların Zaten Uyguladığı Şey Olmalıdır" felsefesiyle yola çıktı ve bu,

HTML Living Standard'ın (HTML5'in temeli) başlangıcı oldu.