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.
<h1>Üst seviye Başlık</h1>
<section>
<h1>İkinci seviye başlık</h1>
<p>Bu section elementi içerisinde bir metin.</p>
<section>
<h1>Üçüncü seviye başlık</h1>
</section>
</section>
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.
<div yapi="header">
Bunu tarayıcılarımızın nasıl algılayacağına bir bakalım.
Elbette bütün tarayıcılarımız bu elementi CSS kullanarak stillendirecektir.
div {color: red}
Peki buna ne dersiniz?
div[yapi] {font-weight: bold}
Aslında neredeyse tüm tarayıcılar, IE7 de dahil, yapi özniteliÄŸine sahip div elementini doÄŸru ÅŸekilde stilleyecektir, hatta yapi özniteliÄŸi olmasa bile ilgili stilleme kullanılabilecektir. Ne yazık ki IE6 bu alanda baÅŸarısız olacaktır. Ama yine de biz bu özniteliÄŸi HTML’de kullanabilir ve en azından tüm tarayıcıları onu tanıyabilmesini saÄŸlayabiliriz. Hatta HTML’mizi stillemek için tüm modern tarayıcılar tarafından desteklenen CSS kullanabiliriz. EÄŸer eski tarayıcılar için de bir hile kullanmamız gerekiyorsa, stilleme için ilgili elemente class özniteliÄŸi için bir deÄŸer atayabiliriz. Bunu ÅŸu an üzerinde çalışılan HTML 5 çözümü ile kıyaslayın. Daha önce de söylediÄŸim gibi HTML 5 üzerindeki çalışmalar, yeni elementler eklenmesi yönünde ilerliyor ancak bu elementler Internet Explorer 6 ya da 7′de stillenemeyecektir. Bu sebeple benim önerimin çok daha geriye dönük uyumlu olduÄŸunu göreceksiniz.
Öznitelikler Üzerinden Geliştirilebilirlik
Yeni elementlerin yerine HTML 5 bir dizi yeni öznitelik içermelidir. Bu özniteliklerin her biri bir semantik kategorisine ya da türüne referans içerecektir. ÖrneÄŸin HTML, yapısal semantikler, sözbilimsel semantikler, rol semantikleri (XHTML’den alınmıştır) ve diÄŸer semantik kategorilerini ve sınıflarını içermektedir.
Bu yeni öznitelikler daha sonra tıpkı class özniteliğinin kullanıldığı gibi kullanılabilirler. Elementin doğasını tanımlamak için element semantiğine eklenebilir ya da element hakkında metaverisi dahil etmek için kullanılabilir.
Bu XHTML’nin role özniteliÄŸinden farklı deÄŸildir, ancak tüm element semantikleri için tek bir öznitelik “sepeti” kullanmaktansa bir element için farklı semantik tiplerini tanımlayabilmemiz ve ardından onları ayırabilmemiz gerekir.
Örneğin, XHTML role özniteliği aşağıdaki şekilde çalışır:
<ul role="navigasyon siteharitasi">
<li href="indirmeler">Downloads</li>
<li href="belgeler">Belgeler</li>
<li href="haberler">Haberler</li>
</ul>
role özniteliğinin değerleri öntanımlı sözlükten ya da özel olarak oluşturulacak bir başka sözlükten alınmış ve boşluklarla ayrılmış kelimelerden oluşur.
Neden role özniteliğini olduğu gibi kullanmıyoruz? Çünkü role teriminin uygun düşmeyeceği başka semantik tipleri de bulunmaktadır. Örneğin:
<p hitabet="ironi">Mükemmel bir kişidir.</p>
“hitabet, semantiklerin teorik tipini güzel bir ÅŸekilde örneklemektedir ve bu yöntemle bir belgenin sözbilimsel kısmı kodlanabilir hale gelecektir. Bu elementin “ironi” rolünü oynayamayacağı apacak ortada. Bunun yerine elementin içeriÄŸi ironiktir.
DiÄŸer bir örnek daha. HTML’nin insan tarafından okunabilir bir deÄŸerin makine tarafından okunabilir biçimini oluÅŸturmak konusunda zayıf kaldığı apaçık ortada. Bu daha önce bahsettiÄŸimiz ve BBC’nin hCalendar mikrobiçimi ile olan probleminin kökeninde yatan durumdur. <span role=”2009-05-01″>Önümüzdeki yıl İşçi Bayramı>/span<” bir anlam ifade etmezken <span equivalent=”2009-05-01″>Önümüzdeki yıl İşçi Bayramı>/span< daha anlamlı olacaktır.
Yine burada da “equivelant” ya da bir benzeri terim kullanmak bir sorun teÅŸkil etmeyecektir. Burada dikkat çekilmesi önemli olan ÅŸey, class özniteliÄŸinde ya da role özniteliÄŸinde olduÄŸu gibi kullanmasının ve adaptasyonunun kolay olmadığıdır. Düzgün bir ÅŸekilde geliÅŸtirilebilir, geriye dönük uyumlu ve gerçek anlamda esneklik sunan bir çözüm için yukarıda anlattıklarımın incelenmesi gerekir.
Bu bölümü “Çözüme Yönelik Düşünceler” olarak isimlendirdim çünkü gerçekten çalışır bir çözüm üretmek için çok büyük bir miktarda çalışma ve hazırlık gerekiyor. Cevabı açık soruları aÅŸağıda listeledim.
- Kaç tane özgün semantik öznitelik bulunmalı? Bu kategoriler geliştirilebilir olmalı mı? Evetse nasıl?
- Sözlükler nasıl belirleniyor?
- Geliştiricilerin class değerlerini diledikleri gibi şekillendirebildikleri gibi dilediğimiz terimleri kendimiz seçebilecek miyiz? Yoksa kullanılabilecek terimler önceden mi belirlenecek? Ya da bir tür profil kullanarak kullanılabilecek değerleri geliştirmek (ve mümkünse de paylaşmak) için bir mekanizma mı oluşturulacak?
- İki sözlük arasında çıkmazda kalırsak, örneğin iki farklı sözlük arasında birbirine benzer terimler gibi, bu durum nasıl çözülecek?
- İsim aralıklandırma için bir tür forma ihtiyacımız var mı ya da buna yönelik bir mekanizma halihazırda mevcut mu?
Bu soruları cevaplandırmak için acele etmektense, üzerlerine düşünmek ve hep beraber tartışmak için soruları yanıtsız bırakıyorum. HTML 5′in sonuçları ve kararların veriliÅŸ süreci çok çetrefilli olduÄŸundan bunlara yönelik son kararı verecek olan kiÅŸilerin dil bilimi, semantikler, semiotikler ve benzer alanlarda uzman olan kiÅŸiler olması gerektiÄŸini düşünüyorum.
Umarım “yeni elementler oluÅŸturmanın”, HTML’nin semantik kapasitesini yükseltmeye yönelik sorunun çözümü olmadığını anlatabilmiÅŸimdir.
Gelin bu kararları çabucak vermeyelim. Zaten torunlarımıza iklim deÄŸiÅŸikliÄŸi gibi büyük bir sorunla mücadele etmek zorunda bırakacak bir hata yaptık. gelin en azından onlara bırakabileceÄŸimiz en iyi HTML’yi bırakalım.
