HTML: s strukturella element - artikel, avsnitt, nav och åt sidan - är vid första anblicken av de enklaste delarna av HTML5-specifikationen att förstå och implementera. Men de är faktiskt några av de mest dåligt specificerade, dåligt förstådda och dåligt genomförda delarna av HTML5.
Skapas godtyckligt De försöker införa ett helt nytt sätt att strukturera webbsidor. de bryter mot HTML: s egna designprinciper; De skadar tillgänglighet för vissa användare. och du borde inte använda dem.
Ja, jag kommer ut vapen-flammande mot den här specifika delen av HTML5, men snälla antar inte att jag är "anti-HTML5". Jag har skrivit en bok om HTML5 , Jag älskar den öppna webben, jag älskar goda webbstandarder, och jag älskar det faktum att efter att ha arbetat genom ett decennium av stagnation sker nu ny teknik i webbteknologi med en helt blåsande hastighet. Det betyder dock inte att vi måste acceptera allt vi får. Vi behöver inte äta allt på HTML5-plattan, även om vi hittar delar av maträtten ganska välsmakande. Vissa delar behöver förmodligen skickas tillbaka till kocken.
Det finns goda och dåliga delar till den ganska enorma HTML5-specifikationen, och vi kommer att tänka kritiskt på en mycket specifik del av specifikationen: snittet eller strukturella element HTML5 introducerar. Så låt oss lägga på våra detektivhattar och titta på var de här nya elementen verkligen kom ifrån, hur de ska användas, och hur vi, webbdesignsgemenskapen, har fundamentalt missförstått dem, vilket väsentligen förkroppar spec. Vi kommer att ifrågasätta själva grunden för dessa element och bryta några myter om dem under vägen.
Låt oss byta en myt som har upprepats ad nauseum om dessa element: tanken att de bygger på forskning om hur vi, webbsamhället, markerade våra dokument. Det är en myt som har upprepats i böcker, bloggar och samtal för flera år nu, och det är bara inte sant. Hur vet jag? Jag frågade.
När jag undersökte dessa elements ursprung bestämde jag mig för att fråga redaktören för HTML5-specifikationen, Ian Hickson, där dessa element kom ifrån. Han svarade:
Mig och andra WHATWG-bidragsgivare [läggs till], [in] 2004ish, eftersom de var uppenbara element att lägga till efter att ha sett hur författare använde HTML4. Vi senare (sen 2005 i början av 2006) gjorde en del objektiv forskning för att ta reda på vad de tio HTML-klasserna var och det visade sig att de i grund och botten exakt matchade de element som vi hade lagt till, vilket var bekvämt.
Låt oss bryta ner det här: Först lade Hickson och WHATWG-medlemmarna till dessa element innan någon forskning gjordes . Du kan dyka in i WHATWGs (tack och lov offentliga) adresslistor arkiv och upptäck tidiga diskussioner om dessa element för dig själv. Du kan till exempel se Hickson diskutera dem i november 2004 med kommentarer som den här :
Ja, jag tänker inkludera saker som [semantiska element] i Web Apps. Whiteboarden på mitt kontor har för närvarande en lista över element under rubriken "HTML5 BLOCK LEVEL ELEMENTS", och jag försöker utarbeta hur man får dem att fungera bra (de aktuella elementen nämns för närvarande i utkastet, men utkastet hanterar inte rubriker alls bra). Jag har inte tittat på inline markup än, men det är också på korten.
Det verkar som om HTML5-strukturens semantik kom ut: en man, en whiteboard och en del inmatningar från andra WHATWG-medlemmar. (WHATWG, eller Web Hypertext Application Technology Working Group, bildades av webbläsarrepresentanter som svar på W3C: s övergivande av HTML för det utopiska idealet för XHTML 2.0).
De element som används av miljontals dokument som vi har diskuterat och diskuterat var, verkar, skapade godtyckligt på ett infall av HTML5-redigeraren 2004. (Och möttes med en skarp kritik och några tyvärr noggranna förutsägelser nästan omedelbart.)
Tantek har insisterat på forskning-före-specificering-nya format under en lång tid i mikroformat-kontexten, och till sist kommer WHATWG-specifikationerna att utformas med faktiska data istället för att vi drar ut saker ur våra kollektiva håll. - Ian Hickson
Det tar oss till den andra punkten. I december 2005 - ett år efter att ha kommit fram till dessa nya element - Hickson (en anställd hos Google) gjorde lite undersökning om hur dokument skapades med Googles stora dokumentdatabas. Forskningen var "en analys av ett urval av drygt en miljard dokument, extrahera information om populära klassnamn, element, attribut och relaterade metadata." ID-nummer inkluderades inte i forskningen. Resultaten publicerades av Google som Web Authoring Statistics (2005) .
Den kritiska delen av forskningen, vad gäller HTML: s strukturella element, var den klasser fynd , som trots att använda ett prov där ~ 900 miljoner av de 1 miljarder dokumenten uppenbarligen inte hade några klasser innehöll några vanliga klasser. Jag är säker på att vi alla har använt i våra projekt innan: footer, meny, titel, liten text , innehåll, rubrik, nav, upphovsrätt, knapp, huvud och så vidare.
Hickson ger sedan sin rotation på data, vilket tyder på att dessa klasser "verkligen [kartlägger] mycket bra till de element som föreslås i HTML5" och ger en tabell som jämför forskningsresultaten och de nya elementen i HTML5: en footer klassen är i undersökningen, ett sidfot är i HTML5; en rubrik är i forskningen, ett huvudelement finns i HTML5; klasserna text , innehåll , huvud , kropp är i forskningen, och felaktigt artikel finns i HTML5 som, som vi ser, inte matchar alls. avsnittet finns inte alls, vilket också är värt att notera.
Tagen till nominellt värde, detta är allt rimligt nog. Jag använder sidfot, du använder sidfot, sidfot är i HTML5. Vad är problemet?
Problemet är, om du läser själva HTML5-specifikation , elementen i HTML5 definieras på ett sätt som inte har något att göra med hur vi traditionellt använt dem.
Å ena sidan har Hickson introducerat ett helt nytt koncept för att strukturera en webbsida i HTML5 med sektionselement . Å andra sidan jämför Hickson hans HTML5-sektionselement till klasser som används i naturen utan att förstå vad de klasserna faktiskt användes för. Ett klassiskt exempel är "header", som de flesta av oss skulle använda för området högst upp på sidan, men HTML5-specifikationen, föreslår att du kan använda den för rubriken för varje kommentar på en sida . Verkligen. Bara för att klasser i forskningen och elementen i HTML5 har samma namn betyder inte att deras användningsområden är desamma.
Nu, om det kommunicerades tydligt att nya element introducerades med ett nytt syfte och en tydlig motivering, då skulle det inte vara så dåligt. Men det är inte vad vi har fått veta.
här är Hickson 2009 , svarar på en fråga om syftet med avsnitt, nav, artikel, åt sidan och andra:
De fyller mer eller mindre de vanligaste förfrågningarna från webbutvecklare baserat på vad de vanligaste klassvärdena för attributvärdena är. Deras huvudsakliga syfte är att förenkla författande och styling.
Tyvärr verkar detta vara ett fall där HTML5-redaktören, för all sitt bra arbete i att dra specen tillsammans, har (låt oss vara generösa) glömt varför han lade till dessa element till vad som i grunden är hans spec. Kanske är det tidsskillnaden mellan 2009 och 2004, vem vet. Men vi vet det här: HTML5-sektionselementen har inte lagts till för att fylla i "de vanligaste förfrågningarna från webbutvecklare" alls. Hur vet vi? Vi kan bara titta på listan och se de mest grundläggande element som läggs till, till exempel sektionselementet (och relaterade artikeln och åtgärdselementen), förekommer inte i den gemensamma klassattributen för forskning alls.
Även om Hickson kanske har glömt varför dessa element har lagts till, kan vi fortfarande tack och lov läsa den spec som dokumenterar deras syfte.
Men vad händer när du säger till webbdesigners och utvecklare att du inte oroar dig, dessa delar ersätter bara vad du redan gör och anger sedan dessa element på ett sätt som verkligen inte är vad webbdesigners och utvecklare gjorde? Du lägger dem på en envägsresa till förvirringsstad.
Det här är den värsta typen av forskning: En lat tolkning av data som gjorts för att motivera beslut som redan gjordes. En ofta upprepad designprincip för HTML5 är att " bana cowpathsna ", det är" När en övning redan är utbredd bland författare, överväg att anta det snarare än att förbjuda det eller uppfinna något nytt. " Och så verkar det med dessa nya strukturella element: sektion, artikel, nav och åt sidan (och sidhuvud och sidfot) -säkert är det bara "banar cowpaths"?
Det är det intryck som många av oss har fått, eftersom det är vad vi har fått veta att de är.
Faktum är att nästan fem år sedan när vi först fick en förhandsgranskning av HTML5 , det såg ut som om dessa element helt enkelt kunde ersätta de "osemantiska" delarna som vi brukade använda. Vad var div id = "header" högst upp på sidan kunde nu bara bli header ; div id = "footer" kunde nu bara bli footer , och vår div kunde bara vara artikel. Enkelt, eller hur?
Tyvärr har vi faktiskt implementerat dessa element på ett sätt som inte återspeglas i HTML5-specifikationen, trots att vi gjorde det vi fick höra (dvs bara byta ut varandra). Det är, när det gäller HTML5-strukturen, har vi väsentligen forked specifikationen. Det finns för närvarande två metoder för HTML5-struktur där ute - gemenskapens tolkning, vilket återspeglas i 2007 A List Apart-artikeln (och otaliga andra); och den faktiska HTML5-specifikationen, som introducerar ett helt nytt sätt att strukturera en webbsida som kallas omtänkande.
Detta är motsägelsen i hjärtat av HTML: s strukturella semantik. Å ena sidan har vi redaktören berättar för oss om de nya elementen är baserade på forskningen om vad vi redan gjorde och är därför avsett att bara göra författningen lite enklare. och å andra sidan har vi det som redaktören faktiskt skapade i HTML5-specifikationen, vilket är ett nytt sätt att strukturera en webbsida på ett sätt som genererar en dokumentutformning med hjälp av sektionselement .
Det var ett tydligt val att göra här. Bryt med HTML5-designprinciperna och introducera någonting nytt, eller helt enkelt följa verkliga författarpraxis och specificera element på ett sätt som speglar webbdesignpraxis. Hickson försökte göra det förra och kalla det senare, och vi har nu en stor röra på våra händer.
Hungrig för mer? Del två 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.
Arbetar du med HTML5 strukturella element? Hittar du dem till hjälp, eller ett hinder? Låt oss veta i kommentarerna.
Utvalda bild / miniatyrbild, användningar strukturbild via Shutterstock.