HTMLs strukturelle elementer - artikkel, seksjon, nav og side - er ved første øyekast noen av de enkleste delene av HTML5-spesifikasjonen for å forstå og implementere. Imidlertid er de faktisk noen av de dårligst spesifiserte, dårlig forstått og dårlig implementerte delene av HTML5.
Skapt vilkårlig; de forsøker å introdusere en helt ny måte å strukturere nettsider på; de bryter med HTMLs eget designprinsipper; de skader tilgjengelighet for noen brukere; og du bør ikke bruke dem.
Ja, jeg kommer ut pistoler mot denne spesifikke delen av HTML5, men vær så snill å ikke anta at jeg er 'anti-HTML5'. Jeg har skrevet en bok om HTML5 , Jeg elsker det åpne nettet, jeg elsker gode webstandarder, og jeg elsker det faktum at etter å ha jobbet gjennom et tiår med stagnasjon, skjer innovasjon i webteknologi nå med en helt blåsende hastighet. Det betyr imidlertid ikke at vi må akseptere alt vi får. Vi trenger ikke å spise alt på HTML5-platen, selv om vi finner deler av parabolen ganske velsmakende faktisk. Noen deler må sannsynligvis sendes tilbake til kokken.
Det er gode og dårlige deler til den ganske enorme HTML5-spesifikasjonen, og vi skal tenke kritisk om en svært spesifikk del av spesifikasjonen: snittet eller strukturelementene HTML5 introduserer. Så la oss sette på detektive hatter og se på hvor disse nye elementene egentlig kommer fra, hvordan de skal brukes, og hvordan vi, webdesign fellesskapet, har fundamentalt misforstått dem, hovedsakelig forking the spec. Vi vil stille spørsmål til selve grunnlaget for disse elementene, og buste noen få myter om dem underveis.
La oss bytte en myte som har blitt gjentatt ad nauseum om disse elementene: ideen om at de er basert på forskning om hvordan vi, nettsamfunnet, markerte opp våre dokumenter. Det er en myte som har blitt gjentatt i bøker, blogger og samtaler i mange år nå, og det er bare ikke sant. Hvordan vet jeg? Jeg spurte.
Da jeg undersøkte opprinnelsen til disse elementene, bestemte jeg meg for å spørre redaktøren for HTML5-spesifikasjonen, Ian Hickson, der disse elementene kom fra. Han svarte:
Meg og andre WHATWG bidragsytere [lagt dem til], [i] 2004ish, fordi de var åpenbare elementer å legge til etter å se hvordan forfattere brukte HTML4. Vi senere (sent 2005 tidlig i 2006) gjorde noen objektiv forskning for å finne ut hva de ti beste HTML-klassene var, og det viste seg at de i utgangspunktet akkurat matchet elementene vi hadde lagt til, noe som var praktisk.
La oss bryte ned dette: Først, Hickson og WHATWG-medlemmene la til disse elementene før det ble gjort noen undersøkelser . Du kan dykke inn i WHATWGs (heldigvis offentlige) adresselistearkiver og oppdage tidlige diskusjoner om disse elementene for deg selv. For eksempel kan du se Hickson diskutere dem i november 2004, med kommentarer som denne :
Ja, jeg har tenkt å inkludere ting som [semantiske elementer] i Web Apps. Whiteboardet på kontoret mitt har for tiden en liste over elementer under overskriften "HTML5 BLOCK LEVEL ELEMENTS", og jeg prøver å finne ut hvordan de får dem til å fungere godt (elementene i spørsmålet er for øyeblikket nevnt i utkastet, men utkastet håndterer ikke hoder i det hele tatt bra). Jeg har ikke sett på inline-oppslag ennå, men det er også på kortene.
Det vil si hvordan HTML5 strukturelle semantikkene kom til å være: en mann, en whiteboard og noen innspill fra andre WHATWG medlemmer. (WHATWG, eller Web Hypertext Application Technology Working Group, ble dannet av nettleserrepresentanter som svar på W3Cs forlatelse av HTML for det utopiske idealet om XHTML 2.0).
Elementene som brukes av millioner av dokumenter som vi har diskutert og diskuterte, virket, skapte vilkårlig på et innfall av HTML5-redaktøren i 2004. (Og ble møtt med en Strålende kritikk og noen trist nøyaktige spådommer nesten med en gang.)
Tantek har lenge insistert på forsknings-før-spesifisering-nye formater i mikronformat-sammenhengen, og til slutt vil WHATWG-spesifikasjonene på samme måte bli utformet med faktiske data, i stedet for at vi trekker ting ut av vår kollektive behinds. - Ian Hickson
Det bringer oss til det andre punktet. I desember 2005 - et år eller så etter å ha kommet opp med disse nye elementene - Hickson (en ansatt hos Google) gjorde noen undersøkelser av hvordan dokumenter ble forfattet ved hjelp av Googles store dokumentdatabase. Forskningen var 'en analyse av et utvalg av litt over en milliard dokumenter, utvinning av informasjon om populære klassenavn, elementer, attributter og tilhørende metadata.' ID-er ble ikke inkludert i undersøkelsen. Resultatene ble publisert av Google som Web Authoring Statistics (2005) .
Den kritiske delen av forskningen, så langt som HTMLs strukturelle elementer var bekymret, var klasser funn , som til tross for å bruke et utvalg hvor ~ 900 millioner av de 1 milliard dokumentene tilsynelatende ikke hadde noen klasser i det hele tatt, inneholdt noen vanlige klasser. Jeg er sikker på at vi alle har brukt i prosjektene våre før: bunntekst, meny, tittel, liten tekst , innhold, header, nav, copyright, button, main, og så videre.
Hickson gir deretter spinnet på dataene, noe som tyder på at disse klassene "egentlig [kartlegger] veldig godt til elementene som foreslås i HTML5 'og gir en tabell som sammenligner resultatene av forskningen og de nye elementene i HTML5: en footer klassen er i undersøkelsen, et bunntekstelement er i HTML5; en header klasse er i undersøkelsen, et headerelement er i HTML5; klassen tekst , innhold , hoved , kropp er i undersøkelsen, og err ... artikkelen er i HTML5 som, som vi ser, ikke samsvarer i det hele tatt; seksjonen finnes ikke i det hele tatt, noe som også er verdt å merke seg.
Tatt til pålydende, dette er alt rimelig nok. Jeg bruker bunntekst, du bruker bunntekst, bunntekst er i HTML5. Hva er problemet?
Problemet er, hvis du leser selve HTML5-spesifikasjon , elementene i HTML5 er definert på en måte som har lite å gjøre med hvordan vi tradisjonelt har brukt dem.
På den ene siden har Hickson introdusert et helt nytt konsept for å strukturere en nettside i HTML5 med seksjonselementer . På den annen side sammenligner Hickson sine HTML5-snittelementer til klasser som brukes i naturen uten å forstå hva de klassene faktisk ble brukt til. Et klassisk eksempel er "header", som de fleste av oss ville bruke for området øverst på siden, men HTML5-spesifikasjonen, foreslår at du kan bruke den til overskriften til hver kommentar på en side . Egentlig. Bare fordi klasser i forskningen og elementene i HTML5 har samme navn, betyr ikke at deres bruk er det samme.
Nå, hvis det ble kommunisert klart at nye elementer ble introdusert med en ny hensikt, og en klar begrunnelse, så ville det ikke vært så ille. Men det er ikke det vi har blitt fortalt.
her er Hickson i 2009 , svare på et spørsmål om formålet med seksjonen, nav, artikkelen, til side og andre:
De fyller mer eller mindre de vanligste forespørsler fra webutviklere basert på hva de vanligste class = "" attributtverdiene er. Deres hovedformål er å forenkle forfatter og styling.
Dessverre synes dette å være et tilfelle hvor HTML5-redaktøren, for alt sitt gode arbeid i å trekke spesifikasjonen sammen, har (la oss være sjenerøse) glemt hvorfor han la disse elementene til det som egentlig er hans spesifikke. Kanskje det er tidsforskjellen mellom 2009 og 2004, hvem vet det. Men vi vet dette: HTML5-delingselementene ble ikke lagt til for å fylle "de vanligste forespørslene fra webutviklere" i det hele tatt. Hvordan vet vi? Vi kan bare se på listen, og se de mest grunnleggende elementene som er lagt til, for eksempel seksjonselementet (og tilhørende artikkel og sideelementer), vises ikke i den vanlige klassen attributter som helst.
Selv om Hickson kanskje har glemt hvorfor disse elementene ble lagt til, kan vi likevel heldigvis lese spesifikasjonen som dokumenterer deres formål.
Men hva skjer når du forteller webdesignere og utviklere ikke å bekymre deg, disse elementene erstatter bare det du allerede gjør, og spesifiser deretter disse elementene på en måte som absolutt ikke er hva webdesignere og utviklere gjorde? Du setter dem på en enveis tur til forvirringsby.
Dette er den verste typen forskning: En lat tolkning av data gjort for å rettferdiggjøre beslutninger som allerede ble gjort. Et ofte gjentatt designprinsipp for HTML5 er å " bane cowpaths ', det er' Når en praksis er allerede utbredt blant forfattere, bør du vurdere å vedta det heller enn å forby det eller finne ut noe nytt. ' Og så virker det med disse nye strukturelle elementene: seksjon, artikkel, nav og til side (og topptekst og bunntekst) - disse er bare "banebrytende"?
Det er det inntrykket mange av oss har, som det er det vi har fortalt at de er.
Faktisk, nesten fem år siden da vi først fikk en forhåndsvisning av HTML5 , det så ut som om disse elementene bare kunne erstatte de "unsemantic" divsene som vi var vant til å bruke. Hva var div id = "header" øverst på siden kunne nå bare bli header ; div id = "footer" kunne nå bare bli en footer , og vår div kunne bare være artikkel. Enkelt, ikke sant?
Dessverre, til tross for å gjøre det vi ble fortalt (dvs. bare bytte ut den ene til den andre), har vi faktisk implementert disse elementene på en måte som ikke reflekteres i HTML5-spesifikasjonen. Det er, når det gjelder HTML5 struktur, har vi i hovedsak forkedet spesifikasjonen. Det finnes for øyeblikket to metoder for HTML5 struktur der ute - samfunnets tolkning, som gjenspeiles i 2007 A List Apart-artikkelen (og utallige andre); og den faktiske HTML5-spesifikasjonen, som introduserer en helt ny måte å strukturere en webside som heter.
Dette er motsetningen i hjertet av HTMLs strukturelle semantikk. På den ene siden har vi redaktøren fortalt oss de nye elementene er basert på forskningen om hva vi allerede gjorde, og er derfor ment å bare gjøre forfatterskap litt lettere; og på den annen side har vi det som redaktøren faktisk opprettet i HTML5-spesifikasjonen, som er en ny måte å strukturere en nettside på på en måte som genererer en dokumentoversikt ved hjelp av snittelementer .
Det var et klart valg å bli gjort her. Bryt med HTML5-designprinsippene og introdusere noe nytt, eller bare følg ekte forfatterpraksis og spesifiser elementer på en måte som reflekterer webdesignpraksis. Hickson prøvde å gjøre det første og kalte det sistnevnte, og vi har nå et stort rot på våre hender.
Sulten for mer? Del to av denne artikkelen er nå tilgjengelig og Luke's bok "The Truth About HTML5" er tilgjengelig i begrenset tid gjennom vår søsterside MightyDeals.com på en fantastisk 50% rabatt.
Fungerer du med HTML5 strukturelle elementer? Finner du dem nyttig, eller en hindring? Gi oss beskjed i kommentarene.
Utvalgt bilde / miniatyrbilde, bruk struktur bilde via Shutterstock.