In het eerste deel van deze serie we hebben de tekortkomingen behandeld die hebben geleid tot de structurele elementen van HTML5, in dit tweede deel zullen we in detail kijken naar de gevolgen van die tekortkomingen.
Ik heb al verschillende keren gezegd dat HTML5 een nieuwe methode introduceert voor het structureren van een webpagina, en je vraagt je waarschijnlijk af wat dat eigenlijk is. Het staat precies in de specificatie, wat introduceert het concept van 'indeelbare inhoud ': segmenterende inhoud is inhoud die de reikwijdte van kopjes en voetteksten definieert. Elk segmenterend inhoudselement heeft mogelijk een kop en een overzicht.
De specificatie documenteert zijn benadering koppen, secties en contouren om het concept duidelijk te maken. Goed, duidelijk voor degenen die de functionaliteit in browsers moeten implementeren. Als we de structurele elementen van HTML (sectie, artikel, nav, opzij en de bijbehorende header- en voettekstelementen) en dit obscure concept van 'sectioning content' of 'outlining' willen begrijpen, moeten we een kleine reis door de HTML-geschiedenis maken.
Het concept van de introductie in HTML5 kan worden teruggevoerd tot 1991 en werd opgenomen in de noodlottige, doodlopende XHTML 2.0-specificatie en zag uiteindelijk het daglicht in HTML5 ... alleen om zo slecht te communiceren dat het idee is vrijwel dood bij aankomst.
Voorafgaand aan HTML5 werd de hiërarchische structuur van een pagina bepaald door de headingelementen - onze oude vrienden h1 tot en met h6. We zouden een pagina kunnen structureren door te zeggen dat de paginatitel h1 is, de artikelkop kan h2 zijn en misschien zijn subkoppen in het artikel h3 en h4, enzovoort.
Dit is prima voor een eenvoudig document, maar het gebruik van heading-tags om een logische hiërarchie of 'documentoverzicht' te maken voor een complexe, moderne webpagina is erg moeilijk. Een deel van het probleem is het ontbreken van een manier om te bepalen waar een paginasectie begint en stopt. Stel dat we ons eerder genoemd document met h1 voor de paginatitel hadden, h2 voor de titel van het artikel, h3 voor de subkoppen, maar we wilden de titel van onze zijbalksecties ook markeren met h3-koppen.
Het documentoverzicht dat zo'n structuur zou maken zou er ongeveer zo uitzien:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Hier worden de h3-elementen 'eigendom' van de h2 erboven, zelfs als het niet veel zin heeft. Natuurlijk zouden we deze opbreken met zoiets als div voor het artikel, en div voor de zijbalk, maar deze worden genegeerd door user-agents (zoals schermlezers) die alleen de structuur van de paginaraam per kop bepalen.
Door de paginarhiërarchie rechtstreeks te koppelen aan wat vaak de koppeniveaus van een presentatie zijn, zijn we beperkt in hoe we een pagina kunnen structureren.
In een poging om dit probleem op te lossen, introduceert HTML5 het concept van 'segmenteerelementen', dat wil zeggen speciale elementen die de pagina verdelen in - u raadt het al - secties, en die secties bepalen het nestingsniveau van headers, en inderdaad de hiërarchie of 'overzicht' van de pagina.
Dat wil zeggen dat de hiërarchie van de pagina is losgekoppeld van de headingelementen en dat deze nieuwe segmentelementen bepalen welk niveau een headingelement eigenlijk is.
In de eerste versie XHTML 2.0-specificatie , segmentering werkte met een sectie-element en een generisch header h-element. Bij het schrijven van HTML zouden we dan niet specificeren welk kopniveau we wilden gebruiken, we lieten de browser eenvoudig het nivelleringsniveau voor een bepaalde kop bepalen. We zouden sectie-elementen 99 niveaus diep kunnen nesten, en een h-element op het 99e niveau zou equivalent zijn aan een h99-element. Op deze manier kunnen we onze documenten logisch structureren, zonder ons zorgen te maken over hoe we de beperkte h1-h6-elementen kunnen gebruiken.
(Dit idee dateert echt van 1991, trouwens: als Jeremy Keith gewezen, Tim Berners-Lee geopperd het idee van een sectie en h-element aan het einde van een pagina structuur deze e-mail van oktober 1991 .)
Hickson probeerde ditzelfde concept in HTML5 te introduceren, maar met een extra moeilijkheidsgraad: hij wilde compatibiliteit met eerdere versies behouden en een nieuwe semantiek introduceren om 'vereenvoudigen van authoring' om op te starten. Daarom hebben we, in plaats van alleen een sectie-element in HTML5, ook een artikel, navigatieblok en opzij element dat allemaal hetzelfde doen als sectie, maar met verschillende namen, om op verschillende manieren te gebruiken.
Wat zegt de spec over deze elementen? Ik moedig je aan om dit te doen lees de specificatie voor jezelf , maar hier is een voorproefje:
Het sectie-element vormt de basis voor het maken van een documentomtrek.
Het sectie-element vertegenwoordigt een generiek gedeelte van een document of toepassing. Een sectie, in deze context, is een thematische groep van inhoud, meestal met een kop.
Voorbeelden van secties zijn hoofdstukken, de verschillende pagina's met tabbladen in een dialoogvenster met tabbladen, of de genummerde secties van een proefschrift. De startpagina van een website kan worden opgesplitst in secties voor een introductie, nieuwsitems en contactgegevens.
Een opmerking in de specificatie zegt dat het element niet voor louter stylingdoeleinden moet worden gebruikt - een div zou daar beter zijn, en begrijpelijkerwijs, aangezien secties die voor het stylen worden gegooid een zeer gebroken documentoverzicht zouden creëren.
De opmerking gaat verder: 'Een algemene regel is dat het sectie-element alleen geschikt is als de inhoud van het element expliciet in de omtrek van het document wordt vermeld' en dat is de duidelijkste verklaring over het sectie-element in de specificatie.
Wanneer we het concept van snijden en schetsen begrijpen, is het zinvol om het sectie-element op te nemen. Het kwam niet voor in het onderzoek naar gemeenschappelijke klassen, maar het kwam wel voor in XHTML 2.0 en gaat conceptueel terug tot 1991.
De andere structurele elementen die HTML5 introduceert - degene die verondersteld werden weerspiegeld in het onderzoek - doen precies hetzelfde als het sectie-element, voor zover het de documentomschrijving betreft. Ze maken ook de hiërarchie van de pagina en daarmee de documentomtrek.
Neem bijvoorbeeld het artikelelement. Veel mensen gaan ervan uit dat het eenvoudigweg om artikelen zoals deze gaat. Maar dat is het helemaal niet. Het is 'artikel' in de betekenis van 'een kledingstuk'. Het wordt beter beschouwd als 'item' dan als 'een kledingstuk', omdat de definitie zo breed is.
Wanneer artikelelementen worden genest, vertegenwoordigen de binnenartikelelementen artikelen die in principe verband houden met de inhoud van het buitenartikel. Een blogitem op een site die door gebruikers ingediende opmerkingen accepteert, kan bijvoorbeeld de opmerkingen vertegenwoordigen als artikelelementen die zijn genest in het artikelelement voor het blogbericht.
In HTML5 zijn gebruikerscommentaren, het eigenlijke artikel, forumposts en zelfs 'interactieve widgets en gadgets' allemaal artikelen. De definitie is zo breed dat ze nutteloos is - semantiek wordt verondersteld betekenis te geven, maar het gebruik van een verzamelterm voor een dergelijke grote verscheidenheid aan items maakt het element zinloos.
Dit is een voorbeeld waarbij we de specificatie hebben gevorkt - een paar mensen volgen de specificatie correct en maken van bijna alles een artikel (blogberichtoverzichten, blogberichten, opmerkingen, widgets, forumberichten, enz.), Terwijl anderen het alleen hebben bewaard voor het hoofdartikel op een pagina, dat slechts een deel van zijn brede definitie is. Je denkt misschien dat het niet uitmaakt hoe dan ook, en in grote mate zou je gelijk hebben. Maar denk eens aan al die leesservices die erop gericht zijn om alleen de hoofdinhoud van de pagina te ontleden. Welke implementatie van de specificatie moeten ze volgen? Moeten ze volgen wat de specificatie precies zegt, of moeten ze de algemene implementatie van de community volgen waar er meestal slechts één canoniek 'artikel' op een pagina staat?
Dit is een gemiste kans, en wat gebeurt er als de specificatie niet echt specificeert , en de redacteur en, om eerlijk te zijn, de gemeenschap, faalt om te communiceren wat de spec feitelijk zegt.
Stel je voor dat het artikel niet ook voor opmerkingen werd gebruikt. Stel je voor dat opmerkingen hun eigen element hebben, bijvoorbeeld, en dat adoptie wijdverspreid is. Browsermakers konden een 'mute comments' functie toevoegen die gemakkelijk opmerkingen op webpagina's kon verbergen (of anderszins parseerden). Maar Hickson heeft specifiek een verzoek om een commentaarelement geweigerd . In HTML5 zijn het artikelen helemaal onderaan.
Afgezien daarvan is een ander element dat nergens voorkomt in het onderzoek naar de naam van Hickson, en krijgt een heel eigenaardige definitie om op te starten:
Het element opzij vertegenwoordigt een gedeelte van een pagina dat bestaat uit inhoud die tangentieel gerelateerd is aan de inhoud rond het element opzij en die als los van die inhoud kan worden beschouwd. Dergelijke secties worden vaak weergegeven als zijbalken in gedrukte typografie.
Het element kan worden gebruikt voor typografische effecten zoals aanhalingstekens of zijbalken, voor reclame, voor groepen nav-elementen en voor andere inhoud die losstaat van de hoofdinhoud van de pagina.
Wie weet waarom opzij zowel aanhalingstekens, zijbalken, advertenties en groepen navigatie-elementen moet omvatten, maar het maakt ook nieuwe secties in de documentomtrek. Dit betekent dat pull-citaten hun eigen opsommingsteken krijgen in de documentomtrek, die, laten we zeggen, 'vreemd' lijkt. Nogmaals, het lukrake gebruik door goedbedoelende webontwerpers heeft en zal veel gebroken documentcontouren creëren.
Het nav-element lijkt het meest vanzelfsprekend te zijn voor de sectiekaders en gelukkig is de definitie niet verder uitgerekt dan breken.
Het nav-element vertegenwoordigt een sectie van een pagina die verwijst naar andere pagina's of naar delen binnen de pagina: een sectie met navigatielinks.
Dat is prima, en zou theoretische toegankelijkheidsvoordelen kunnen hebben (een user-agent zou voorbij kunnen springen, of naar de nav-links kunnen springen - dat doen ze niet, maar dat zouden ze wel kunnen).
Het probleem is dat we in de geest van 'vereenvoudigen van authoring' en het vervangen van div door het nav-element de navigatiestijl voor een andere subset gebruikers opblazen. Gebruikers van IE6-8 met JavaScript uitgeschakeld (Yahoo's onderzoek suggereert 1-2% van alle gebruikers hebben JavaScript uitgeschakeld ) zijn het slachtoffer van dit probleem. Als JavaScript uit staat, werkt JavaScript-gebaseerde HTML5-shim die IE6-8-HTML5-elementen helpt niet, zodat HTML5-elementen in de browser niet worden gemodelleerd. Dit is mogelijk alleen van invloed op een klein aantal gebruikers, maar waarom zijn ze überhaupt van invloed?
De header- en voettekst-elementen zijn een klassiek geval van veelvoorkomende termen en zeer verschillende gebruiksmogelijkheden.
De specificatie geeft aan dat geen van deze elementen nieuwe secties in de documentomtrek creëren, ondanks het feit dat ze vaak worden afgebeeld als gelijk aan sectie, nav, artikel en terzijde. In feite doen ze helemaal niets. Ze zijn alleen opgenomen om gebieden van een specifieke sectie in de documentomtrek af te bakenen.
Dit is wat de spec zegt over de header: het header-element vertegenwoordigt een groep inleidende of navigatiehulpmiddelen.
Opmerking: een headerelement is meestal bedoeld om de kop van de sectie (een h1-h6 element of een hgroup element) te bevatten, maar dit is niet vereist. Het header-element kan ook worden gebruikt om de inhoudsopgave van een sectie, een zoekformulier of andere relevante logo's in te pakken.
en voettekst: het voettekstelement vertegenwoordigt een voettekst voor de dichtstbijzijnde inhoud voor het segmenteren van secties of voor het segmenteren van het wortelelement. Een voettekst bevat meestal informatie over de sectie, zoals wie deze heeft geschreven, links naar gerelateerde documenten, auteursrechtgegevens en dergelijke.
In HTML5 is het body-element eigenlijk het rootsectie-element, dus een algehele header- en voettekst is bedoeld om de root-bodysectie te beschrijven. Elke sectie kan een koptekst en / of een voettekst bevatten. Ze zijn niet alleen bedoeld voor algemene kop- en voetteksten, zoals we wellicht hebben aangenomen. Individuele opmerkingen kunnen elk een kop- en voettekst hebben, bijvoorbeeld. In feite, zoals we eerder al hebben gezegd, geeft de specificatie feitelijk een voorbeeld van een footer die wordt gebruikt in een opmerking boven de daadwerkelijke inhoud van de opmerking. Dat klopt, in HTML5 zijn commentaren artikelen en kunnen ze een voettekst hebben voor een koptekst, en dat is in de eigenlijke specificatie. Wilt u een voettekstelement voor de koptekst van uw opmerkingen? Nee? Nou, je hebt er een.
Nogmaals, dit is waar HTML5 veelgebruikte termen gebruikt en deze gebruikt op manieren die voor de gewone webauteur onherkenbaar zijn.
Maar er is iets waar we niet naar gekeken hebben in HTML's implementatie van snijden. Heb je het gezien? We hebben de sectiekaders, maar we hebben geen generiek h-element. Geen zorgen, de oplossing is in de spec :
Secties kunnen koppen van elke rang bevatten, maar auteurs worden sterk aangemoedigd om alleen h1-elementen te gebruiken, of om elementen van de juiste rangorde te gebruiken voor het nesteniveau van de sectie.
HTML5 wil achterwaarts compatibel zijn, dus de WHATWG heeft besloten geen h-element te introduceren (ondanks het introduceren van een hoop nieuwe sectie-elementen), maar in plaats daarvan het h1-element opnieuw te gebruiken als het generieke h-element. Gebruik overal h1 en laat het HTML5-algoritme het ware niveau bepalen ... of zo gaat de theorie.
Dit is een vreselijk idee om verschillende redenen, de twee belangrijkste zijn toegankelijkheid en styling.
Het gebruik van h1 overal is erg slecht voor de toegankelijkheid. Blinde gebruikers zijn sterk afhankelijk van de headingstructuur van een site. Het is belangrijk voor ons allemaal om eraan herinnerd te worden hoe cruciaal de koersstructuur is voor toegankelijkheidsdoeleinden. Bijvoorbeeld een december Onderzoek van 2008 onder meer dan 1000 gebruikers van schermlezers uitgevoerd door WebAIM bleek dat 76% van de blinde en slechtziende gebruikers 'altijd of vaak' genavigeerd door rubrieken wanneer ze beschikbaar waren. En uit een enquête van mei 2012 bleek dat positieniveaus van 82,1% 'erg handig' of 'enigszins bruikbaar' waren bij het navigeren op een webpagina. (Dit is goed, praktisch onderzoek, dus let op.)
H1s overal hebben, maakt sites moeilijker te navigeren voor blinde gebruikers. In theorie zouden schermlezers in plaats daarvan het algoritme van HTML gebruiken en navigeren met behulp van de documentomtrek, maar gezien de manier waarop auteurs zijn verteld om snijelementen toe te passen, is schetsen een puinhoop en probeert te navigeren door documentomtrekken waaraan geen enkele gedachte is gegeven nog erger zijn voor blinde gebruikers.
De HTML5-specificatie biedt een uitweg: gebruik de juiste h1-h6-niveaus om compatibiliteit met eerdere versies te handhaven. Maar nu handhaven we twee documentcontouren in het ene document, en gezien de problemen die auteurs hebben gehad, zelfs in de eerste plaats de documentomtrek, de kans dat iemand een logisch h1-h6 overzicht behoudt en een logische, correct -gescheterde HTML5-outline lijkt op zijn best op afstand.
Maar het wordt erger. Laten we zeggen dat we willen werken met een zuivere HTML5-omtrek en we gebruiken overal h1s. Vergeet niet dat in de HTML5-specificatie de h1 slechts een algemeen h-element is; het werkelijke niveau wordt bepaald door hoe diep het genest is in de sectiekaders.
Dus hoe kunnen we het stylen? Welnu, we kunnen klassennamen aan al onze h1-elementen toevoegen, zodat we ze kunnen uitzoeken, maar dat is in strijd met het gestelde doel van HTML5 om het ontwerpen te vereenvoudigen; en we kunnen net zo goed vasthouden aan h1-h6 (die allemaal worden behandeld als generieke h-elementen in een HTML5-overzicht).
We kunnen proberen ze door de cascade heen te stijlen, maar dit wordt al snel absurd, zoals Nicole Sullivan heeft erop gewezen . In feite begint 'absurd' het alleen maar te beschrijven. Wanneer u de mogelijke combinaties van sectie, artikel, nav en opzij overweegt en u een generieke stijl wilt maken voor een kop die bijvoorbeeld vijf niveaus diep is (dat wil zeggen het equivalent van h5), zou u stijlen moeten schrijven voor alle mogelijke combinaties, wat wordt volslagen idioot . Dit is de generieke stijl voor een h3-element:
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;}Maar dat is wat HTML's structurele elementen ons geven. Wat een puinhoop.
Honger naar meer? Deel drie van dit artikel is nu beschikbaar en Luke's boek "The Truth About HTML5" is voor een beperkte tijd beschikbaar via onze zustersite MightyDeals.com met een verbazingwekkende 50% korting.
Gebruik je artikelelementen meerdere keren in een document? Zijn secties nuttig of moeten we bij div's blijven? Laat ons je mening weten in de reacties.
Uitgelichte afbeelding / miniatuur, gebruik structuur afbeelding via Shutterstock.