İçinde bu serinin ilk kısmı HTML5'in yapısal unsurlarına yol açan hataları ele aldık, bu ikinci bölümde bu başarısızlıkların sonuçlarına ayrıntılı olarak bakacağız.
HTML5'in bir web sayfası yapılandırması için yeni bir yöntem getirdiğini ve muhtemelen bunun gerçekte ne olduğunu merak ettiğinizi defalarca söyledim. Orada, spesifikasyon var 'bölümleme içeriği' kavramını tanıtıyor ': bölümleme içeriği, başlıkların ve altbilginin kapsamını tanımlayan içeriktir. Her bölüm içerik elemanı potansiyel olarak bir başlık ve bir taslak içerir.
Şartlar onun yaklaşımını belgeliyor başlıklar, bölümler ve anahatlar kavramı netleştirmek için. Eh, tarayıcılarda işlevselliği uygulamak zorunda olanlar için temizleyin. HTML'nin yapısal unsurlarını (bölüm, makale, nav, bir kenara ve ilgili öğeleri üstbilgisi ve altbilgisi) ve bu '' içerik bölümlerini 'veya' ana hatlarını çizme 'kavramını anlayabilmemiz için HTML tarihi boyunca küçük bir yolculuk yapmamız gerekiyor.
HTML5'te tanıtılan ana hat kavramı 1991'e kadar izlenebiliyor ve kötü niyetli, çıkmaz XHTML 2.0 spesifikasyonlarına dahil edildi ve son olarak gün ışığını HTML5'te görüyordu… sadece bu fikri çok zayıf bir şekilde iletiyordu. varışta oldukça fazla öldü.
HTML5'ten önce, bir sayfanın hiyerarşik yapısı başlık öğeleri tarafından belirlendi - eski dostlarımız h1'den h6'ya. Sayfa başlığı h1, makale başlığı h2, belki de makaledeki alt başlıklar h3 ve h4 vb. Şeklinde bir sayfa yapılandırabiliriz.
Bu basit bir belge için iyidir, ancak karmaşık, modern bir web sayfası için mantıksal bir hiyerarşi veya 'belge taslağı' oluşturmak için başlık etiketlerini kullanmak çok zordur. Sorunun bir kısmı, bir sayfa bölümünün nerede başladığını ve durduğunu belirlemenin bir yolunun olmaması. Örneğin, daha önce bahsettiğimiz belgeyi sayfa başlığı için h1, makale başlığı için h2, alt başlıklar için h3 olduğunu, ancak daha sonra h3 başlıklarıyla birlikte kenar çubuğu bölümlerimizin başlığını işaretlemek istediğimizi varsayalım.
Böyle bir yapının oluşturduğu belge taslağı şöyle bir şeye benzeyecekti:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Burada, h3 öğeleri, çok anlamlı olmasa bile, üstlerindeki h2 tarafından "sahiplenir". Tabii ki, biz bu makale için div ve div için div gibi bir şey ile kırmak, ama bunlar tek başına başlık yapısı ile sayfa anahat belirleyen kullanıcı ajanlar (ekran okuyucular gibi) tarafından göz ardı edilir.
Sayfa hiyerarşisini doğrudan sunum başlığı seviyelerine bağlayarak, bir sayfayı nasıl yapılandırabileceğimiz konusunda sınırlıyız.
Bu problemi çözmeye yönelik bir girişimde, HTML5, 'bölümleme elemanları' kavramını, yani, sayfayı sayfalara bölen, tahmin ettiğiniz bölümleri bölen özel unsurları ve bu bölümlerin başlıkların yuvalanma düzeyini ve gerçekten de hiyerarşiyi belirlediğini sunar. veya sayfanın 'anahatlarını'.
Yani, sayfanın hiyerarşisi başlık öğelerinden ayrılmamıştır ve bunun yerine, bu yeni bölümleme öğeleri, bir başlık öğesinin gerçekte ne düzeyde olduğunu belirler.
İlk taslakta XHTML 2.0 belirtimi , bölümleme bir bölüm elemanı ile çalıştı ve bir genel başlık h elemanı. HTML yazarken, hangi düzeyde kullanmak istediğimizi belirleyemeyiz, sadece tarayıcının belirli bir başlık için yuvalama seviyesini belirlemesine izin verirdik. Bölüm elemanlarını 99 seviye derinliklerine ayırabiliriz ve 99. seviyedeki bir h elemanı bir h99 öğesine eşdeğer olabilir. Bu şekilde, sınırlı h1-h6 öğelerini nasıl kullanabileceğimiz konusunda endişelenmeden belgelerinizi mantıklı bir şekilde yapılandırabiliriz.
(Bu fikir gerçekten de 1991'e kadar uzanmaktadır, bu arada: Jeremy Keith Tim Berners-Lee, bir bölüm ve h unsuru fikrinin sonunda bir sayfa yapısını vurguladı. bu Ekim 1991 e-postası .)
Hickson, aynı kavramı HTML5'e dahil etmeye teşebbüs etti, ancak ek bir zorluk derecesiyle: geriye dönük uyumluluğunu sürdürmek ve 'yazma sürecini basitleştirmek' için bazı yeni anlamlar tanıtmak istedi. Bu nedenle, HTML5'te sadece bir bölüm elemanına sahip olmak yerine, bölümle aynı şeyi yapan ancak farklı isimlerle farklı şekillerde kullanılabilecek bir makale, nav ve bir kenara sahibiz.
Spesifik bu unsurlar hakkında ne söylüyor? Seni teşvik ederim kendiniz için spec okuyun ama burada bir tat:
Bölüm elemanı, bir belge taslağı oluşturmak için bölümlemenin temelidir.
Bölüm elemanı, bir belgenin veya uygulamanın genel bir bölümünü temsil eder. Bu bağlamda bir bölüm, tipik olarak bir başlık ile tematik bir içerik gruplandırmasıdır.
Bölüm örnekleri, bölümler, sekmeli iletişim kutusundaki çeşitli sekmeli sayfalar veya bir tezin numaralı bölümleri olabilir. Bir web sitesinin ana sayfası bir giriş, haber öğeleri ve iletişim bilgileri için bölümlere ayrılabilir.
Spekülasyonda yer alan bir not, elemanın tamamen şekillendirici amaçlar için kullanılmaması gerektiğini söyler - bir div orada daha iyi olurdu, ve anlaşılır bir şekilde, stil için willy-nilly'de atılan bölümler çok bozuk bir belge taslağı oluşturacaktır.
Not, 'Genel bir kural, bölüm öğesinin, yalnızca öğenin içeriği belgenin anahattında açıkça listeleniyorsa uygun olur ve bu özellik, bölümdeki bölüm öğesiyle ilgili en net ifadedir.
Bölümlendirme ve özetleme kavramını anladığımızda, bölüm elemanının dahil edilmesi mantıklıdır. Ortak sınıf değerleri araştırmasında görünmüyordu, ancak XHTML 2.0'da ortaya çıktı ve kavramsal olarak 1991'e kadar uzanıyor.
HTML5'in sunduğu diğer yapısal elemanlar - araştırmaya yansıttığı iddia edilenler-, belge taslağı ile ilgili olarak, bölüm taslağı ile aynı şeyi yaparlar. Ayrıca, sayfanın hiyerarşisini ve dolayısıyla belge taslağını oluştururlar.
Örneğin makale elemanını alın. Birçok insan, bunun gibi makaleler için olduğunu varsaymaktadır. Ama bu hiç de değil. 'Giysi eşyası' anlamında 'makale'. Tanımı o kadar geniş olduğu için, 'giyim' öğesinde olduğu gibi 'madde' olarak düşünülür.
Eşya elemanları iç içe geçtiğinde, iç eşya elemanları, prensip olarak, dış nesnenin içeriği ile ilgili olan eşyaları temsil etmektedir. Örneğin, bir sitede kullanıcı tarafından gönderilen yorumları kabul eden bir blog girişi, yorumları blog girişi için makale öğesinin içine yerleştirilmiş makale öğeleri olarak gösterebilir.
HTML5'te kullanıcı yorumları, makaleye uygun, forum gönderileri ve hatta 'etkileşimli widget'lar ve araçlar' makaleleridir. Bu tanım, işe yaramayacak kadar geniş - anlambiliminin anlam katması gerekiyordu, ancak bu kadar geniş çeşitlilikteki öğeler için kolektif bir terim kullanmak, unsuru anlamsızlaştırıyor.
Bu, spesifikasyonları belirttiğimiz bir örnektir - bazı kişiler spesifikasyonları doğru bir şekilde takip eder ve hemen hemen her şeyi bir makale haline getirirler (blog yazısı özetleri, blog gönderileri, yorumlar, aletler, forum mesajları, vb.). geniş tanımının sadece bir parçası olan bir sayfadaki ana makale için. Her iki yolun bir önemi olmadığını düşünebilirsin ve büyük ölçüde haklı olabilirsin. Ancak, sayfanın ana içeriğini ayrıştırmayı amaçlayan tüm okuma servislerini düşünün. Spesifikasyonun hangi uygulamalarını takip etmeleri gerekiyor? Spekülasyonların söylediklerini takip etmeli mi yoksa bir sayfada genellikle tek bir kanonik 'makale' olan genel toplum uygulamasını mı izlemeli?
Bu, kaçırılan bir fırsattır ve şartname gerçekte belirtmeyi başaramadığı zaman gerçekleşir ve editör ve adil olmak için topluluk, gerçekte söylediği şeyleri aktarmakta başarısız olur.
Makalenin yorumlarda da kullanılmadığını hayal edin. Örneğin, yorumların kendi unsurlarına sahip olup olmadığını düşünün ve evlat edinme yaygınlaştı. Tarayıcı yapıcılar, web sayfalarındaki yorumları kolayca gizleyebilecek (veya başka bir şekilde ayrıştırabilecek) bir 'sessiz yorumları' işlevi ekleyebilir. Ancak Hickson, özellikle bir yorum öğesi için bir talebi reddetti . HTML5'te makaleler tamamen aşağı doğru.
Bir yana, Hickson'un sınıf adı araştırmasında herhangi bir yerde görünmeyen ve önyükleme yapmak için çok tuhaf bir tanım olan başka bir unsur:
Bir kenara eleman, bir kenara göre içerik ile teğetsel olarak ilgili olan ve bu içerikten ayrı düşünülebilecek içerikten oluşan bir sayfanın bir bölümünü temsil eder. Bu bölümler genellikle basılı tipografide kenar çubukları olarak temsil edilir.
Öğe, çekme tırnakları veya kenar çubukları, reklam için, nav öğeleri grupları için ve sayfanın ana içeriğinden ayrı olarak kabul edilen diğer içerikler gibi yazımsal efektler için kullanılabilir.
Kimin bir kenara çekilip çıkarılmaması gerektiğini, kenar çubuklarını, reklamı ve gezici öğelerin gruplarını kapsaması gerektiğini kim bilebilir, ancak belge anahattında da yeni bölümler oluşturur. Bu, çekme tekliflerinin belge özetinde kendi mermi noktalarını alması anlamına gelir, ki bu da 'garip' diyelim. Yine, iyi niyetli web tasarımcıları tarafından gelişigüzel kullanımı, birçok kırık belge ana hatları oluşturuyor ve oluşturacak.
Nav elemanı, kesit elemanlarının en açıklayıcı görünümü gibi görünüyor ve şükür ki, tanım kırılmanın ötesine uzamış değil.
Nav elemanı, başka sayfalara veya sayfadaki bölümlere bağlantı veren bir sayfanın bir bölümünü gösterir: Gezinme bağlantılarına sahip bir bölüm.
Bu iyi ve teorik erişilebilirlik avantajlarına sahip olabilir (bir kullanıcı aracısı atlayabilir veya nav bağlantılar atlayabilir - yapamaz, ama yapabilirler).
Sorun, 'yazarlığı basitleştirmenin' ruhuyla ve div öğesini nav elemanıyla değiştirerek, başka bir kullanıcı alt kümesi için gezinme stilini patlatmamızdır. JavaScript kapalı IE6-8 kullanıcıları (Yahoo'nun araştırması öneriyor Tüm kullanıcıların% 1-2'si JavaScript kapalı ) Bu sorunun kurbanıdır. JavaScript kapalıyken, IE6-8'in HTML5 öğelerini anlamasına yardımcı olan JavaScript tabanlı HTML5 yapısı çalışmaz, bu nedenle tarayıcı HTML5 öğelerini biçimlendirmez. Bu sadece az sayıda kullanıcıyı etkileyebilir, ancak neden onları etkiler?
Üstbilgi ve altbilgi öğeleri, ortak terimler almak ve onlara çok farklı kullanımlar vermek için kullanılan klasik bir durumdur.
Spesifikasyonlar, bu unsurlardan hiçbirinin, genellikle, bölüm, nav, makale ve bir kenara eşit olarak tasvir edilmelerine rağmen, belge taslağında yeni bölümler oluşturmadığını belirtir. Aslında hiç bir şey yapmıyorlar. Belge taslağında belirli bir bölümün alanlarını ayırmak için sadece dahil edilmiştir.
Özelliğin başlık hakkında söylediği şu şekildedir: başlık öğesi bir tanıtım veya gezinme aracı grubunu temsil eder.
Not: Bir başlık elemanının genellikle bölümün başlığını (bir h1 – h6 öğesi veya bir h grup elemanı) içermesi amaçlanmıştır, ancak bu gerekli değildir. Başlık öğesi, bir bölümün içeriğini, bir arama formunu veya ilgili logoları sarmak için de kullanılabilir.
ve altbilgi: alt öğe, en yakın ataşman bölümleme içeriği veya bölüm kök öğesi için bir altbilgiyi temsil eder. Altbilgi, genellikle kimin yazdığı, ilgili belgelere bağlantılar, telif hakkı verileri ve benzeri gibi bölümüyle ilgili bilgiler içerir.
HTML5'te, gövde elemanı aslında kök bölüm öğesidir, dolayısıyla genel bir üstbilgi ve altbilgi kök gövdesi bölümünü açıklamak için tasarlanmıştır. Herhangi bir bölüm bir üstbilgiye ve / veya altbilgiye sahip olabilir; yalnızca üstbilgiler ve altbilgiler için değil, varsaydığımız gibi tasarlanmıştır. Bireysel yorumların her biri örneğin bir üstbilgi ve altbilgiye sahip olabilir. Aslında, daha önce de değindiğimiz gibi, gerçekte, gerçek yorum içeriğinin üzerinde bir yorumda kullanılan altbilgi örneği verilir. Bu doğru, HTML5 yorumlarında makalelerdir ve bir başlık için altbilgiye sahip olabilirler ve bu, gerçek belirtimindedir. Yorumunuzun başlığı için altbilgi unsuru mu istediniz? Yok hayır? Peki, bir tane var.
Yine, bu, HTML5'in ortak terimler alması ve bunları ortak web yazarı için tanınmayacak şekilde kullanır.
Ancak, HTML’nin bölümlendirme uygulamasında bakmadığımız bir şey var. Gördün mü? Bölümleme elemanlarımız var, ancak genel bir h elementimiz yok. Endişelenme, çözüm spesifik olarak :
Bölümler herhangi bir sıradaki başlıkları içerebilir, ancak yazarların ya sadece h1 öğelerini kullanmaları ya da bölümün yuvalanma düzeyi için uygun sıralamanın öğelerini kullanmaları şiddetle tavsiye edilir.
HTML5 geriye dönük olarak uyumlu olmak ister, bu yüzden WHATWG bir h elemanını (bir dizi yeni kesit elemanını tanıtmasına rağmen) getirmemeye karar verdi ve bunun yerine h1 elemanını jenerik h elemanı olarak yeniden tanımlamak istiyor. Her yerde h1 kullanın ve HTML5 anahatlama algoritmasının gerçek seviyesini belirleyelim… ya da teori böyle devam eder.
Bu iki nedenden ötürü, erişilebilirlik ve şekillendirme olmak üzere birkaç nedenden dolayı korkunç bir fikirdir.
H1'i her yerde kullanmak erişilebilirlik için çok kötü. Kör kullanıcılar, bir sitenin başlık yapısına büyük ölçüde bağlıdır. Hepimizin, önemli olan başlık yapısının erişilebilirlik amaçları için ne kadar önemli olduğunu hatırlatması önemlidir. Örneğin, Aralık 1000'den fazla ekran okuyucu kullanıcısı 2008 anketi WebAIM tarafından yapılan araştırmada, görme engelli ve görme engelli kullanıcıların% 76'sının, her zaman ya da çoğu zaman, mevcut olduğunda, başlıklar tarafından yönlendirildiği bulunmuştur. Mayıs 2012'de yapılan bir ankette, bir web sayfasında gezinirken% 82.1'lik yönlendirme düzeylerinin “çok yararlı” veya “biraz yararlı” olduğu görülmüştür. (Bu iyi, pratik araştırma, not al.)
Her yerde h1'e sahip olmak, siteleri kör kullanıcılar için gezinmek için zorlaştırır. Teorik olarak, ekran okuyucular HTML'nin anahatlama algoritmasını kullanacaklar ve belge taslağını kullanarak yönlendireceklerdi, ancak yazarlara bölümleme elemanlarını uygulamalarının anlatıldığı şekilde verildiğinde, özetlemenin bir karışıklık olduğu ve hiçbir düşünce verilmeyen belgenin ana hatları arasında gezinmeye çalışıldığı görüldü. Kör kullanıcılar için daha da kötü.
HTML5 özelliği bir çıkış yolu sunar: geriye doğru uyumluluğu sağlamak için uygun h1-h6 seviyelerini kullanmaya devam edin. Ancak şu anda bir belgede iki belge ana hatlarını tutuyoruz ve yazarların her şeyden önce belge taslağını bile göz önünde bulundurarak, mantıksal bir h1-h6 taslağını ve mantığını düzgün bir şekilde kullanabilme olasılıkları göz önünde bulundurulduğunda En iyi şekilde çekilmiş HTML5 anahatları uzak görünüyor.
Ama daha da kötüye gidiyor. Saf bir HTML5 anahat ile çalışmak istediğimizi ve her yerde h1 kullanıyoruz. Unutmayın, HTML5 spesifikasyonunda h1 sadece genel bir h öğesidir; gerçek seviyesi, bölümleme elemanlarının içinde ne kadar derin bir şekilde yer aldığıyla belirlenir.
Öyleyse onu nasıl şekillendireceğiz? Peki, tüm h1 öğelerine sınıf adlarını ekleyebiliriz, böylece onları seçebiliriz, fakat bu, belirtilen HTML5'in yazarlığı basitleştirme amacına aykırıdır; ve h1-h6'ya da yapışabiliriz (hepsi bir HTML5 anahatta genel h öğeleri olarak ele alınır).
Onları çağlayana göre deneyebilir ve stil verebiliriz, ancak bu hızlıca saçma olur. Nicole Sullivan dikkat çekti . Aslında, 'saçma' sadece onu tarif etmeye başlar. Bölüm, makale, nav ve kenara ait olası kombinasyonları düşündüğünüzde ve sözgelimi, beş seviye derinlikte (yani h5'in karşılığı) genel bir stil oluşturmak istediğinizde, her biri için stil yazmanız gerekir. olası kombinasyonları alır kesinlikle gülünç . İşte bir h3 öğesi için genel stil:
article aside nav h1, article aside section h1,article nav aside h1, article nav section h1,article section aside h1, article section nav h1, article section section h1,aside article nav h1, aside article section h1,aside nav article h1, aside nav section h1,aside section article h1, aside section nav h1, aside section section h1,nav article aside h1, nav article section h1,nav aside article h1, nav aside section h1,nav section article h1, nav section aside h1, nav section section h1,section article aside h1, section article nav h1, section article section h1,section aside article h1, section aside nav h1, section aside section h1,section nav article h1, section nav aside h1, section nav section h1,section section article h1, section section aside h1, section section nav h1, section section section h1 {font-size: 1.00em;}Yine de HTML'nin yapısal unsurları bize bu. Ne dağınıklık.
Daha fazlası için aç? Bu makalenin üçüncü kısmı şu anda hazırdır ve Luke'un "HTML5 Hakkında Gerçekler" adlı kitabı, kardeş sitemiz aracılığıyla sınırlı bir süre için kullanılabilir MightyDeals.com inanılmaz bir% 50 indirim.
Bir makalede makale öğelerini birden çok kez kullanıyor musunuz? Bölümler faydalı mı yoksa div'lara bağlı mıyız? Yorumlarınız ile düşüncelerinizi öğrenmemize izin verin.
Öne çıkan görsel / küçük resim, kullanımlar yapı görüntüsü Shutterstock üzerinden.