I den första delen av denna serie vi tittade på de brister som leder till att de strukturella elementen är nya i HTML5; i den andra delen av serien vi tittade i detalj på konsekvenserna av dessa misslyckanden; i den här sista delen kommer vi leta efter en väg framåt och dra några slutsatser om det aktuella läget.
Detta är inte ett abstrakt problem: människor måste faktiskt lära sig dessa saker. Nästa generations webbdesigners och utvecklare lärs ut med HTML5 som utgångspunkt. Jag är ledsen för den som måste försöka förklara skiss och snitt till nuvarande och framtida grödan av studenter. Kanske kommer de klokt att hålla sig till det enkla formatet vi har som fortfarande fungerar bra: använd divs med antingen ID eller klass / es.
Det är rimligt att föreslå att kanske användaragenter i framtiden, till exempel webbläsare och skärmsläsare, kommer att göra mer med HTML5s strukturella element, och det gör dem mer tilltalande för oss som författare.
Operaens Bruce Lawson föreslog bara det på WHATWG-postlista 2009 :
När allt kommer omkring vet jag om ingen användaragenter som kan använda tid, avsnitt, sidfot, datagrid etc men vi förväntar oss mest att det snart kommer.
Och här är vad Hickson, HTML5-redaktören, sa som svar:
Jag gör inte. De flesta av de nya elementen är bara avsedda att göra styling enklare, så att vi inte behöver använda klasser.
Allt detta, och redaktören ser inte användaragenter någonsin att använda dessa element. De är där, säger han, för att rädda oss från att använda klasser. Sätt på ett annat sätt, skaparen av dessa element verkar osäkra varför de är ens i specifikationen, spara "att göra styling enklare".
Det finns en tankeskola som säger att vi bara behöver en handfull ny semantik ändå. När allt kommer omkring skulle det bli uppblåst om det fanns tiotals eller hundratals nya villkor läggas till.
Å ena sidan håller jag med. När det gäller att strukturera en grundläggande webbsida, skulle jag säga att vi skulle vara bättre utan HTML-sektionselementen helt och hållet. Vad som en gång var en enkel övning i att använda div har blivit en komplicerad röra i HTML5 utan någon nettovinst.
Men vad gäller semantik i allmänhet finns det fall där mer mening kan läggas ovanpå strukturen på vår webbsida (vare sig det är HTML4, 5 eller vad som än kommer nästa) med ytterligare attribut på våra befintliga element.
En av de enklaste sakerna att genomföra på en befintlig eller ny webbplats är ARIA landmärken. (ARIA står för Tillgängliga Rich Internet Applications och är en specifikation som definierar ett sätt att göra webbapplikationer och webbsidor mer tillgängliga.)
ARIA-landmärken är en delmängd av den övergripande ARIA-specifikationen, och en enkel typ av metadata som gör det möjligt för blinda och synskadade användare att använda skärmsläsare att hoppa till de signifikanta delarna av en sida, dvs "landmärken". Vi lägger helt enkelt till roll = "landmärke-namn" till ett befintligt element, på samma sätt som vi skulle lägga till class = "class-name" till ett element. AIRA landmärken är diskuteras i jämförelse med HTML5 här .
ARIA landmärken är en mycket bättre match för vad vi för närvarande gör. Namnet är lite wonky, men åtminstone de speglar den faktiska webbförfattande praxis. Till exempel kan vi använda:
(Tänk på att banner-, huvud- och innehållsinformation endast ska användas en gång per dokument.)
ARIA-landmärken är en enkel lösning som förbättrar navigeringsalternativen för användarna av skärmläsare utan att behöva gå in i det dunkla området för HTML-dokumentet. De är snabba och enkla att implementera, och borde verkligen vara en del av din grundläggande HTML-projektmall.
Så vi har mer semantik för tillgänglighet, men vi har också mer semantik tillgänglig för sökmotorer också.
Först, låt mig vara helt klar att HTML5-element har ingen fördel för SEO alls. Det är en myt, och vi måste lägga den till sängs. Att använda en artikel tagg hjälper dig inte eller din kund rankar högre än nästa kille. Du kan lita på att Google har funderat på hur du hittar och rankar ditt innehåll nu.
Men sökmotorer är angelägna om att förstå hur bäst att visa (notera: inte ranka ) webbinnehåll på ett mer strukturerat sätt.
Därför har de stora sökmotorerna genom åren lagt fram eller antagit befintliga vanliga sätt att markera strukturerad data på en webbsida så att de kan extrahera lämplig information. När du söker efter recensioner kan du till exempel märka att stjärnklassificeringar visas i de bästa resultaten från Google. Det här är fallet att sökmotorer kan extrahera granskningsresultatet på ett standardiserat sätt och förbättra visningen av resultaten. Recept är ett annat exempel, där tillagningstiden anges för varje resultat. Medan sådana data inte förbättrar platsens rankning, kan det mer detaljerade resultatet uppmuntra fler användare att klicka igenom, så det finns en viss potentiell fördel där för en webbplats, och det är ofta nödvändigt i en vapenlöpssituation där alla dina konkurrenter gör det i alla fall.
Medan denna typ av rik data har funnits ett tag i olika dimensioner, bara förra året de stora sökmotorerna lanserade en stor ny uppsättning standarder för denna typ av strukturerad data. De ringer dem "scheman", och de är inrymda på Schema.org . De använder HTML: s mikrodatastandard, och har redan implementerats av t.ex. eBay, IMDB, Rotten Tomatoes och mer.
Detta är det största språnget mot en mer semantisk webb i år, men ändå gjordes det bakom stängda dörrar med liten fanfare och ingen standardprocess alls. Det släpptes på oss utan varning och har sedan dess mestadels flown under webbdesigns communitys radar. Det finns också mycket överlappning med HTML5 semantik, till exempel finns scheman för artiklar , webb sidor och webben sidelement , bland fler scheman som inkluderar allt från TV-episoder till medicinska tillstånd . Det är också rekommenderat sätt att beskriva videor på webben.
Efter hela debatten om HTML-semantiken (och bristen på det) har sökmotorerna gjort det klart att de vill ha mycket mer semantiska data i vår uppställning, men det kommer att hända ovanpå befintliga strukturer, och inte med nya element.
Men säkert för oss som en gemenskap som är intresserad av semantik och webbstandarder är inte heller HTML: s begränsade, bristfälliga tillvägagångssätt för semantik eller den slutna, bortkastade nollanvändningen hos de stora sökmotorerna den bästa vägen framåt.
I vissa sinnen har HTML5-semantikhästen bultat; Det är bara upp till oss att innehålla skadan. När det gäller schema.org är det en helt ny värld, och vi bör granska mycket nära, eller en annan liten grupp ska bestämma vad som ligger i vår - och webben - bästa för oss. Faktum är att det kanske redan har hänt.
Låt oss slå in med några slutsatser.
Det finns många bra delar i HTML5-specifikationen, från nya formulärfunktioner till History API och Canvas implementation. Faktum är att WHATWG, som varit drivkraften bakom HTML5, faktiskt inte stod fast med HTML4 / XHTML 1.0 medan vi väntade på W3C att få sin handling tillsammans. Ändå beror det bara på att HTML5 och all relaterad teknik kring den är ny och spännande betyder det inte att vi måste acceptera allt vi får.
Ibland är det värt att se hur HTML-korven görs, så vi vet vad vi äter. Och när det gäller HTML-strukturella semantik, skulle jag hellre gå vidare.
Hungrig för mer? Luke's bok "The Truth About HTML5" är tillgänglig för en begränsad tid genom vår systersida MightyDeals.com med en fantastisk 50% rabatt.
Har du använt ARIA landmärken eller Schema.org? Ser du en framtid för HTML5s strukturella element? Låt oss veta i kommentarerna.
Utvalda bild / miniatyrbild, användningar strukturbild via Shutterstock.