Bir öngörüde bulunacağım. Siz ve ben bu dünyadan göçtükten çok sonra bile HTML halen kullanılıyor olacak. Sırf bizim çağımızda arşivlenen milyarlarca sayfa değil, yaşayan ve nefes alan bir varlık olarak hayatını sürdürecek. Çok fazla gayret, enerji ve yatırım web’in araçlarına, protokollerine ve platformlarına harcandı.Bizim buradaki sorumluluğumuzu düşünmeyi bir kenara bırakalım. Geçmişteki hatalar sebebiyle, uygarlığımızın yıllar boyunca birbirleri ile iletişim kurmak için kullanacakları önemli bir aracı geliştirmeye kendimizi adadık. Bu yüzden umursamadan ya da gerçekten umursayarak bu durumu kafamıza taktığımızda, HTML’yi iyileştirmek için, bugün verdiğimiz kararların sonuçlarının ne kadar ileriye dönük olacağını anlamamız gerekiyor.W3C’nin HTML’nin yeni nesli için inanılmaz çaba harcadığı HTML 5, özellikle son bir iki yıldır dikkatleri üzerine çekmeye başladı. Bu gerçekten çok büyük bir proje ve sadece HTML’nin yapısını kavramakla kalmıyor, bunun yanısıra sözdizimsel analiz modelleri, hata işleme modelleri, DOM, kaynak alım modelleri, medya içeriği, 2B çizim, veri şablonlama, güvenlik modelleri, sayfa yükleme modelleri, istemci taraflı veri depolama ve çok daha fazlasını içeriyor.Ayrıca Lachian Hunt’ın HTML 5 Ön İncelemesi yazısında da kavradığı gibi HTML’nin yapısında, kodunda ve semantiklerinde de değişiklikler yapılıyor.Biz bu yazı için HTML’nin semantiklerini ele alacağız. Bu benim birkaç yıldır ilgilendiğim bir konu ve bunun HTML’nin geleceği için hayati önem taşıdığına inanıyorum.BBC’nin geçtiğimiz günlerde yaptığı bir açıklamaya göre kurum, abbr tasarım şablonu‘na yönelik olan kullanılabilirlik ve erişilebilirlik endişeleri nedeniyle, program listelerinden hCalendar mikrobiçimini kullanmayı bırakacak. Buradan çıkarmamız gereken ders, geçen zaman içerisinde HTML’nin amacından çok daha ötesine geçtiğimiz ve HTML’nin semantik olanaklarını zorladımız olmalıdır. Özetle daha zengin semantik belgeler oluşturabilmek için kullanabileceğimiz kodları tükettik. Eğer HTML’nin halihazırda bulunan yapılarını zeki bir şekilde kullanmaya devam edersek, daha fazla problem gün yüzüne çıkacaktır. Ancak HTML ne yazık ki semantik bir kodlama dili olmaktan çok uzaktadır, semantikleri sabittir ve geliştirilebilir değildir.Bu sadece basit bir teori problemi değildir. Yüzbinlerce geliştirici class ve id HTML değerlerini daha zengin semantik kod yazmak için kullanmaktadırlar (ayrıca yine aynı geliştiriciler bunları CSS stilleme için birer “çengel” olarak kullanmaktadırlar ancak bu başka bir konu). Neredeyse hiç değişmeden bu geliştiriciler ad hoc (belirli bir amaç için düzenlenmiş, kendi oluşturdukları) sözlükleri kullanmaktadırlar. Kullanılan değerler, halihazırda kullanılan şemalardan alınmaktansa kendileri tarafından geliştirilmiştir. Bu en iyi ihtimalle sahte semantik kodlama olarak isimlendirilebilir.
Web üzerinde kullanılan pek çok sayfa, HTML’nin fakirleşmiş elementlerini ve değerlerini, daha iyi bir yapıya sahip semantikleri belgelerine eklemek için mikrobiçimler kullanmaktadırlar. Bu durumda, class özniteliği için kullanılan değerler kabul görmüş sözlüklerden gelmektedir, bazen ise bu değerler vCard gibi standartlardan esinlenirken, bazen de hReview gibi herhangi oturmuş ve kabul görmüş bir standardı bulunmayan, sadece belirli bir amaca hizmet eden kaynaklardan esinlenmiştir.Geliştirilebilir Semantikler
Burada çözülmesi gereken çok gerçek bir problem bulunmaktadır. Geliştiricilerin belgelerine daha zengin ve anlamlı semantikler ekleyebilecekleri HTML mekanizmalarına ihtiyacımız bulunmaktadır, sahte semantiklere değil. HTML 5’in üzerine en büyük baskıyı oluşturan konunun bu olduğunu söylemek yalan olmaz.Ancak bu HTML içeriğinde daha zengin semantik oluşturmak için bir mekanizma geliştirmek kadar kolay bir iş değildir, uygulanabilecek her bir çözümün bazı olumsuz tarafları bulunmaktadır. Belki de bunlardan en önemlisi geriye dönük uyumluluktur. Sunulacak çözüm, günümüzde kullanılan yüz milyonlarca aygıtı kullanılamayacak hale getirmemelidir ki bu aygıtlar, önümüzdeki yıllarda da kullanılmaya devam edecektir. Geriye dönük uyumluluğu olmayan hiçbir çözüm, geliştiriciler tarafından okurlarını kaybetmek korkusuyla geniş bir şekilde kabul görmeyecektir, aksine kısa bir süre içerisinde yok olacaktır.Sunulacak olan çözüm ayrıca ileriye dönük olmalıdır. Burada gelecek yıllarda piyasaya sürülecek aygıtlarla uyumlu olması gerektiğinden bahsetmiyorum, bu tarayıcı geliştiricilerinin sorunudur. Burada anlatmak istediğim şey, sonucun geliştirilebilir olmasıdır. Günümüzde geliştireceğimiz herhangi bir çözümün varolan ve olası tüm sorunları çözmesini beklememiz doğru olmaz. Geliştirilebilir ve geleceğin ihtiyaçlarına yardımcı olacak bir çözüm sunabiliriz.
Bu iki kısıtlama birbirini takip etmektedir ve büyük bir zorluk oluşturmaktadır. Ancak konu iki durum arasında on yıl bulunan bir kodlama dili olduğunda ve bu kodun önemi iletişim için bir global platform çatısı altında birleşmişse, karşı karşıya olduğumuz bu zorluğun aşılması gerekmektedir.Peki HTML 5 bu sorunu nasıl ele alıyor? HTML 5 üzerinde bir dizi yeni element bulunuyor. Bunlardan bazıları benim “yapısal” olarak adlandırdığım section, nav, aside, header ve footer elementleridir. dialog elementi bir tür içerik (content) elementidir ve blockquote‘ye benzemektedir. Bunun yanısıra bazı veri elementleri de bulunmaktadır. Örneğin meter (metre) elementi “bilinen bir aralık içerisinde sayısal bir ölçümü ya da kısmi bir değeri temsil eder; örneğin disk kullanımı gibi” ve time” elementi bir tarihi ya da zamanı temsil eder.Her ne kadar bu elementler kullanışlı olabilirken ve şimdilik ilgileri üzerine çekmişken, yukarıda bahsettiğimiz, özellikle geriye dönük ve ileriye yönelik problemleri çözebilecek kapasitede midir?Gelin her bir kısıtlamayı ele alalım.Geriye Dönük Uyumluluk
Peki section gibi bu yeni elementleri halihazırda kullandığımız tarayıcılar nasıl ele alıyorlar? Aslında Safari, Opera, Mozilla ve hatta IE7 bile aşağıdaki şekilde kodlanmış bir sayfayı işleyeceklerdir.

Mükemmel bir başlangıç gibi görünüyor. Ancak CSS ile örneğin section elementini aşağıdaki şekilde stillemeye kalktığımızda:section: {color: red}
…yukarıda bahsettiğimiz tarayıcıların pek çoğu stillemeyi doğru bir şekilde yapacaktır, ancak IE7 (ve muhtemelen IE6) bunu doğru şekilde uygulamayacaktır.O zaman burada ciddi bir geriye dönük uyumluluk sorunu ile karşı karşıyayız. Günümüzde kullanılan tarayıcıların ortalama %75’i Internet Explorer sürümlerini oluşturuyor. Internet Explorer’ın yarı ömrünü göz önüne aldığımızda, önümüzdeki birkaç yıl boyunca bile kullanıcıların pek çoğunun IE6 ve IE7 kullanacağını öngörebiliriz.Eğer HTML 5 bu yeni elementlerle gelirse, geliştiricilerin bu elementleri sitelerine entegre etmelerindeki olasılık nedir? Özellikle ziyaretçilerinin %75’inin bu kodlarla işlenmiş siteleri düzgün bir şekilde göremeyeceklerini göz önüne aldığımızda geliştiricilerin bu kodları kullanmalarındaki olasılık iyice düşmektedir.Ne yazık ki class özniteliğini section elementleriniz üzerinde kullanarak bu sorunu gidermeyi düşünüyorsanız, bu yöntem de IE üzerinde çalışmayacaktır. Burada belki de bu sorunu çözebilecek bir yöntem geliştirilebilir ancak geliştirilmedikçe bu durum önemli bir sorun teşkil etmeye devam edecektir.
Gelin ikinci kısıtlamamız olan ileriye yönelik uyumluluk durumunu ele alalım.İleriye Yönelik Uyumluluk
Burada bir soru ile başlayacağız: “bu yeni elementleri neden icat ediyoruz?” Bu soruya verilebilecek cevap “HTML’nin semantik zenginlikten yoksun olduğu ve bu yeni elementleri ekleyerek HTML’nin semantik zenginliğini arttırmış oluruz – bu da kötü bir şey değil, değil mi?” olacaktır.Bu elementleri ekleyerek, HTML’nin daha iyi semantik yeteneklere sahip olmasına yönelik bir sorunu ele alıyoruz, ancak daha dar bir alan içerisinde. Ne kadar yeni elemente sırtımızı dayarsak dayayalım, HTML’ye ekleyeceğimiz daha iyi semantikleri göz önünde bulundurmaya devam edeceğiz. Bunun sonucunda da ne kadar yeni element kullanırsak kullanalım, halen sorunu çözmemiş olacağız. HTML sözlüğüne özgün terimler eklememiz gerekmiyor. Burada gereken şey, belgelere, gerektiğinde semantik zenginlik katabilecek bir mekanizma eklememiz gerekiyor. Teknik açıdan bu, HTML’yi geliştirilebilir yapmamız gerektiği anlamına geliyor. HTML 5, geliştirilebilirlik için hiçbir mekanizma sunmamaktadır.
HTML 5 bunun yerine geçerli tarayıcıların büyük bir çoğunluğunu gözden çıkaran bir özellik getiriyor ve ilgili dile hiçbir şekilde yeni semantik zenginlik katabilmemizi sağlamıyor.
Bu yeni elementlere yönelik birkaç soru halen geçerliliğini koruyor. Bu yeni elementlerin adları nereden geliyor? Yeni bir navigasyon elementi olması gerektiğine ve bunun adının “nav” olması gerektiğine nasıl karar verildi? Neden aynı terim sayfa genelinde, site genelinde ve siteler genelinde kullanılmakta?
Neden Docbook gibi halihazırda kullanılan bir sözlük kullanılmasın? Docbook, bir belge yapı sözlüğü olup HTML 5’ten çok daha zengin ve yayımlama uzmanları tarafından yıllardır kullanılıyor. Aslında bu Docbook yanlısı bir tartışma değil. Burada belirtmek istediğim şey, HTML’ye semantik zenginlik kazandırmak proje bazında bireysel çabalarla gerçekleştiriliyor ve 30 yıldan daha uzun zaman önce temelleri atılan açılımlardan en ufak bir miktarda bile esinlenilmiyor (GML üzerindeki ilk çalışmalar 1970lere dayanıyor).Çözüme Yönelik Düşünceler
Günümüzde bu sorunları gidermeye yönelik çabalara dair eleştirilerimizi sıraladıktan sonra, bu problemi çözmek için bir önerim var mı? En azından bir tane olmalı.Eğer HTML’ye yeni elementler eklemek olanaklar dahilinde olmasaydı, ya da en azından bu tartışma dahilinde olmasaydı, HTML’nin üzerine konsantre olabileceği bir diğer mantıksal alan öznitelikler olacaktır. Hepsi bir yana neredeyse 10 yıla yakın bir süredir, HTML’nin semantiklerini geliştirmek için class ve id özniteliklerini kullanıyoruz. Bu yüzden eğer bu problemi çözmek için öznitelikleri kullanacaksak, yeni öznitelikler geliştirmemiz gerekiyor. Bunun nasıl çalışacağını anlatmaya geçmeden önce, HTML 5’in yeni elementleri için gereksinimlerimizin bu öznitelikler için de geçerli olduğunu söylemek yerinde olur. En önemlisi, HTML’ye yeni öznitelikler eklemek geriye dönük uyumlu olacak mıdır? Eğer olacaksa HTML’de semantik geliştirilebilirlik için çalışır bir mekanizma sunacak mıdır?
Gelin yeni bir öznitelik icat edelim. Bunu ben “yapi” olarak isimlendireceğim ancak burada kullanacağımız ismin önemi yoktur. Bunu şu şekilde kullanabiliriz.