I den första delen av denna serie vi täckte de misslyckanden som leder till HTML5s strukturella element, i denna andra del kommer vi att se i detalj på konsekvenserna av dessa misslyckanden.
Jag har sagt flera gånger att HTML5 introducerar en ny metod för att strukturera en webbsida, och du undrar nog vad det egentligen är. Det är precis där i spec, vilket introducerar begreppet sektionsinnehåll ': Sektionsinnehåll är innehåll som definierar räckvidden för rubriker och sidfot. Varje sektionsinnehållsdel har potentiellt en rubrik och en översikt.
Specifikationen dokumenterar sin inställning till rubriker, avsnitt och skisser för att göra konceptet klart. Tja, klart för dem som måste implementera funktionaliteten i webbläsare. För att vi ska kunna förstå HTML-strukturella element (avsnitt, artikel, nav, åt sidan och deras relaterade elementrubrik och sidfot) och detta dunkla koncept "sektionsinnehåll" eller "skissera", måste vi ta en liten resa genom HTML-historiken.
Konceptet som beskrivs i HTML5 kan spåras fram till 1991 och inkluderades i den misshandlade, dödliga XHTML 2.0-specifikationen, och ser slutligen dagens ljus i HTML5 ... bara för att vara så dåligt kommunicerad att idén är ganska död vid ankomsten.
Före HTML5 bestämdes den hierarkiska strukturen för en sida av rubrikelementen - våra gamla vänner h1 till h6. Vi kunde strukturera en sida genom att säga sidtiteln är h1, artikelrubriken kan vara h2 och kanske underrubriker i artikeln kan vara h3 och h4 osv.
Det här är bra för ett enkelt dokument, men det är väldigt svårt att använda rubriker för att skapa en logisk hierarki, eller "dokumentutformning", för en komplex och modern webbsida. En del av problemet är bristen på ett sätt att bestämma var en sidavdelning startar och slutar. Till exempel, säg att vi hade vårt tidigare nämnda dokument med h1 för sidtiteln, h2 för artikelnamnet, h3 för underrubrikerna, men ville sedan markera titeln för våra sidofält sektioner med h3-rubriker också.
Dokumentet som en sådan struktur skulle skapa skulle se ut så här:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Här ägs h3-elementen av h2 ovanför dem, även om det inte ger stor mening. Självklart skulle vi bryta upp dem med något som div för artikeln och div för sidofältet, men dessa ignoreras av användaragenter (som skärmsläsare) som bestämmer sidplanen med enbart rubrikstruktur.
Genom att koppla sidhierarkin direkt till vad som ofta är presentationsnivåer är vi begränsade i hur vi kan strukturera en sida.
I ett försök att lösa detta problem introducerar HTML5 begreppet "sektionselement", det vill säga specialelement som delar upp sidan - du gissar det - sektioner, och de här sektionerna bestämmer nästningsnivån för rubrikerna och i själva verket hierarkin , eller "skiss" på sidan.
Det vill säga, hierarkin för sidan är kopplad från rubrikelementen, och i stället bestämmer de nya sektionselementen vilken nivå ett rubrikelement faktiskt är.
I det första utkastet XHTML 2.0 specifikation , snittning arbetat med ett snittelement och ett generiskt header h-element. När vi skrev HTML, skulle vi inte ange vilken nivå av rubrik vi ville använda, vi skulle helt enkelt låta webbläsaren bestämma nivån för en viss rubrik. Vi kunde näsa sektionselement 99 nivåer djupt, och ett h-element på 99: e nivå skulle motsvara ett h99-element. På så sätt kan vi strukturera våra dokument logiskt, utan att oroa oss för hur vi kan använda de begränsade h1-h6-elementen.
(Den här ideen går verkligen tillbaka till 1991, förresten: som Jeremy Keith påpekade, Tim Berners-Lee mooted idén om en sektion och h element att strukturera en sida i slutet av denna oktober 1991 e-post .)
Hickson försökte introducera samma begrepp i HTML5, men med en svårare svårighet: han ville behålla bakåtkompatibilitet och introducera några nya semantik för att "förenkla författandet" för att starta upp. Därför har vi, istället för att bara ha ett avsnittelement i HTML5, en artikel, nav och åt sidan element som alla gör samma sak som avsnitt men med olika namn som ska användas på olika sätt.
Vad säger specimen om dessa element? Jag uppmuntrar dig att läs specimen för dig själv , men här är en smak:
Sektionselementet är grunden för sektionering för att skapa en dokumentbeskrivning.
Sektionselementet representerar en generisk del av ett dokument eller en applikation. En sektion är i detta sammanhang en tematisk gruppering av innehåll, typiskt med en rubrik.
Exempel på sektioner skulle vara kapitel, de olika fliksidorna i en flikad dialogruta eller de numrerade avsnitten i en avhandling. En webbplatss hemsida kan delas upp i avsnitt för en introduktion, nyhetsartiklar och kontaktuppgifter.
En anteckning i specifikationen säger att elementet inte ska användas för rent stylingändamål - en div skulle vara bättre där, och förståeligt så, eftersom sektioner som kastades i willy-nilly för styling skulle skapa en mycket bruten dokumentbeskrivning.
Noten fortsätter med att säga "En allmän regel är att sektionselementet endast är lämpligt om elementets innehåll skulle anges exakt i dokumentets disposition" och det är det tydligaste påståendet om avsnittet i specifikationen.
När vi förstår begreppet snittning och skissering är delningen av delelementet meningsfullt. Det förekommit inte i den gemensamma klassvärdesforskningen, men det visade sig i XHTML 2.0 och går tillbaka till begreppsmässigt till 1991.
De andra strukturella elementen HTML5 introducerar - de som antagligen reflekterades i forskningen - gör exakt samma sak som avsnittet, så långt som i dokumentet. De skapar också sidans hierarki, och därmed dokumentets disposition.
Ta artikelelementet till exempel. Många människor antar att det bara är för artiklar som den här. Men det är inte alls. Det är "artikel" i betydelsen av "en klädesartikel". Det är bättre tänkt på som "föremål" som i "en klädesplagg", eftersom dess definition är så bred.
När artikelelement är kapslade representerar de inre artikelelementen artiklar som i princip är relaterade till innehållet i den yttre artikeln. En blogginmatning på en webbplats som accepterar användarinlämnade kommentarer kan till exempel representera kommentarerna som artikelelement som är inbädda i artikelelementet för blogginmatningen.
I HTML5 är användar kommentarer, artikeln korrekt, foruminlägg och till och med "interaktiva widgets och gadgets" alla artiklar. Definitionen är så bred att den inte är användbar - semantiken ska ge mening, men med en kollektiv term för så många olika objekt gör elementet meningslöst.
Det här är ett exempel där vi har förkedat specifikationen - några personer följer specifikationen korrekt och gör nästan allt en artikel (blogginläggsöversikter, blogginlägg, kommentarer, widgets, foruminlägg, etc.), medan andra bara har behållit det för huvudartikeln på en sida, som bara är en del av dess breda definition. Du kanske tror att det inte spelar någon roll, och i stor utsträckning skulle du ha rätt. Men tänk på alla de som läser tjänster som syftar till att bara analysera huvudinnehållet på sidan. Vilket genomförande av specifikationen ska de följa? Ska de följa vad specifikationen säger eller ska de följa det allmänna samhällets genomförande där det vanligtvis bara finns en kanonisk artikel på en sida?
Det här är ett missat tillfälle, och vad händer när specifikationen inte faktiskt specificerar , och redaktören och, för att vara rättvis, samhället, misslyckas med att kommunicera vad specifikationen säger.
Tänk om artikeln inte också användes för kommentarer. Tänk om kommentarer fick sitt eget element, till exempel, och adoption blev utbredd. Webbläsare kan lägga till funktionen "dämpa kommentarer" som enkelt kan dölja (eller på annat sätt tolka) kommentarer på webbsidor. Men Hickson har specifikt vägrat en begäran om ett kommentarelement . I HTML5 är det artiklar hela vägen ner.
Bortsett är ett annat element som inte finns någonstans i Hicksons klassnamn forskning, och får en mycket märklig definition för att starta:
Bortsettningselementet representerar en sektion av en sida som består av innehåll som är tangentiellt relaterat till innehållet kring sidan, och som kan anses vara separat från det innehållet. Sådana sektioner representeras ofta som sidofält i tryckt typografi.
Elementet kan användas för typografiska effekter som dragkurser eller sidofält, för reklam, för grupper av navelement och för annat innehåll som anses vara skilt från huvudinnehållet på sidan.
Vem vet varför åt sidan borde täcka både dra citationstecken, sidofält, annonsering och grupper av navigeringselement, men det skapar också nya avsnitt i dokumentet. Det betyder att dra citationstecken får sin egen punkt i dokumentet, vilket tycks säga, "udda". Återigen har dess slumpmässiga användning av välsignade webbdesigners och kommer att skapa många brutna dokumentutskrifter.
Navelementet verkar mest självförklarande av sektionselementen, och tack och lov har definitionen inte sträckts utöver att bryta.
Nav-elementet representerar en sektion av en sida som länkar till andra sidor eller delar på sidan: ett avsnitt med navigationslänkar.
Vilket är bra och kan ha teoretiska tillgänglighetsfördelar (en användaragent kan hoppa över eller hoppa till nav-länkarna - de gör det inte, men de kan).
Problemet är att i andan att "förenkla författandet" och ersätta div med navelementet blåser vi upp navigeringsmodellen för en annan delmängd av användare. Användare av IE6-8 med JavaScript off (Yahoo: s forskning föreslår 1-2% av alla användare har JavaScript inaktiverat ) är offer för detta problem. Med JavaScript, det JavaScript-baserade HTML5-shim som hjälper IE6-8 förstår HTML5-element fungerar inte, så webbläsaren stämmer inte HTML5-element. Det här kan bara påverka ett litet antal användare, men varför påverkar dem alls?
Huvud- och sidfotelementen är ett klassiskt fall att ta vanliga termer och ge dem mycket olika användningsområden.
Specifikationen anger att ingen av dessa delar skapar nya avsnitt i dokumentet, trots att de ofta är avbildade som i nivå med avsnitt, nav, artikel och åt sidan. Faktum är att de inte gör någonting alls. De är bara inkluderade för att avgränsa områden av en viss sektion i dokumentet.
Här är vad specifikationen säger om rubrik: rubrikelementet representerar en grupp inledande eller navigationshjälpmedel.
Obs! Ett rubrikelement är avsett att normalt innehålla rubrikens rubrik (ett h1-h6-element eller ett hgroupelement), men detta är inte nödvändigt. Rubrikelementet kan också användas för att pakka in en sektions innehållsförteckning, en sökformulär eller eventuella relevanta logotyper.
och sidfot: sidfotelementet representerar en sidfot för dess närmaste förfader-sektionsinnehåll eller snittrotselement. En sidfot innehåller vanligen information om sin sektion, som vem skrev det, länkar till relaterade dokument, upphovsrättsdata och liknande.
I HTML5 är kroppselementet faktiskt rotsektionselementet, så en övergripande rubrik och sidfot är avsedd att beskriva rotkroppsdelen. Varje sektion kan ha en rubrik och / eller en sidfot - de är inte avsedda bara för övergripande rubriker och sidfot, som vi kanske har antagit. Individuella kommentarer kan till exempel ha en rubrik och en sidfot. I själva verket, som vi berörde tidigare, ger specifikt ett exempel på sidfot som används i en kommentar ovanför själva kommentarinnehållet. Det är rätt, i HTML5 kommentarer är artiklar, och de kan ha en sidfot för en rubrik, och det är i själva specifikationen. Vill du ha ett sidfot för rubriken av dina kommentarer? Nej? Tja, du har en.
Återigen är det här HTML5 tar vanliga termer och använder dem på sätt som inte är igenkännliga för den gemensamma webbförfattaren.
Men det finns något som vi inte har tittat på i HTML: s implementering av sektionering. Såg du det? Vi har sektionselementen, men vi har inte ett generiskt h-element. Oroa dig inte, lösningen är i spec :
Sektioner kan innehålla rubriker av vilken rang som helst, men författare uppmanas starkt att antingen använda endast h1-element eller använda element av lämplig rang för sektionens nästningsnivå.
HTML5 vill vara bakåtkompatibel, så WHATWG bestämde sig för att inte introducera ett h-element (trots att man införde en massa nya sektionselement) och istället vill omforma h1-elementet till det generiska h-elementet. Använd h1 överallt, och låt HTML5 skissera algoritmen bestämma sin sanna nivå ... eller så går teorin.
Det här är en hemsk idé av flera anledningar, de två viktigaste är tillgänglighet och styling.
Att använda h1 överallt är mycket dåligt för tillgänglighet. Blinda användare är starkt beroende av rubrikstrukturen på en webbplats. Det är viktigt för oss alla att påminnas om hur viktig huvudstruktur är för tillgänglighetsändamål. Till exempel en december 2008-undersökning av över 1000 skärmläsare användare genomförd av WebAIM fann att 76% av blinda och synskadade användare alltid eller ofta navigerade med rubriker när de var tillgängliga. Och en maj 2012-undersökning fann att 82,1% kursnivåer var "mycket användbara" eller "något användbara" när du navigerade på en webbsida. (Det här är bra, praktisk forskning, så notera.)
Att ha över hela världen kommer att göra webbplatser svårare att navigera för blinda användare. I teorin skulle skärmsläsare använda HTML: s överblickande algoritm istället och navigera med hjälp av dokumentet, men med tanke på hur upphovsmännen har fått höra att implementera sektionselement, är det en röra, och man försöker navigera i dokumentskisser som inte har funnits någonting alls vara ännu värre för blinda användare.
HTML5-specifikationen ger en väg ut: använd lämpliga h1-h6-nivåer för att behålla bakåtkompatibilitet. Men nu upprätthåller vi två dokumentutskrifter i det ena dokumentet, och med tanke på de problem som författarna har haft jämnt överens om dokumentets disposition i första hand, sannolikheten för att någon bibehåller både en logisk h1-h6 skiss och en logisk korrekt -Sected HTML5-skissen verkar i fjärrkontroll, i bästa fall.
Men det blir värre. Låt oss säga att vi vill köra med en ren HTML5 skiss, och vi använder h1s överallt. Kom ihåg att i HTML5-specifikationen är h1 bara ett generiskt h-element; dess verkliga nivå bestäms av hur djupt den är inbäddad i snittelementen.
Så hur stilar vi det? Tja, vi kunde lägga till klassnamn på alla våra h1-element så att vi kan välja ut dem, men det strider mot det angivna HTML5-målet för att förenkla författningen. och vi kan också hålla oss till h1-h6 (alla som behandlas som generiska h-element i en HTML5-översikt).
Vi kan försöka stile dem genom kaskaden, men det blir snabbt absurt, som Nicole Sullivan har påpekat . Faktum är att "absurt" bara börjar beskriva det. När du överväger de möjliga kombinationerna av avsnitt, artikel, nav och åt sidan, och du vill skapa en generisk stil för en rubrik, det vill säga fem nivåer djupt (dvs motsvarande h5), måste du skriva stilar för alla möjliga kombinationer, vilket får helt löjligt . Här är den generiska stilen för ett 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;}Men det är vad HTML: s strukturella element ger oss. Vilken röra.
Hungrig för mer? Del tre i denna artikel är nu tillgänglig och Lukas bok "The Truth About HTML5" är tillgänglig under en begränsad tid genom vår systersida MightyDeals.com med en fantastisk 50% rabatt.
Använder du artikelelement flera gånger i ett dokument? Är sektioner användbara eller ska vi hålla fast vid divs? Låt oss veta dina tankar i kommentarerna.
Utvalda bild / miniatyrbild, användningar strukturbild via Shutterstock.