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.
işte bende bunlardan kullandıgım bir tanesini sizinle paylaşıyorum..telkin dediysem..çok düşük bi frekansta..algılamanız oldukça zordur..buyrun bu mp3 ayrıca;
