HTML's strukturelle elementer - artikel, afsnit, nav og side - er ved første øjekast nogle af de nemmeste dele af HTML5-specifikationen til at forstå og implementere. Men de er faktisk nogle af de mest dårligt specificerede, dårligt forstået og dårligt implementerede dele af HTML5.
Skabt vilkårligt de forsøger at introducere en helt ny måde at strukturere websider på; de overtræder HTML's eget design principper; de skader tilgængeligheden for nogle brugere; og du bør ikke bruge dem.
Ja, jeg kommer ud i kanoner - flammende mod denne specifikke del af HTML5, men vær så snill at gå ud fra, at jeg er 'anti-HTML5'. Jeg har skrevet en bog om HTML5 , Jeg elsker det åbne web, jeg elsker gode webstandarder, og jeg elsker det faktum, at efter at have arbejdet gennem et årti af stagnation, sker innovation i webteknologier nu med en helt blærende hastighed. Det betyder dog ikke, at vi skal acceptere alt, hvad vi får. Vi behøver ikke at spise alt på HTML5-pladen, selvom vi finder dele af parabolen ret velsmagende. Nogle dele skal sandsynligvis sendes tilbage til kokken.
Der er gode og dårlige dele til den ganske enorme HTML5-specifikation, og vi tænker kritisk på en meget specifik del af specifikationen: de sektionære eller strukturelle elementer HTML5 introducerer. Så lad os sætte vores detektivhatte på og se på, hvor disse nye elementer virkelig kom fra, hvordan de skal bruges, og hvordan vi, webdesign samfund, har fundamentalt misforstået dem, hovedsagelig forking spec. Vi vil stille spørgsmålstegn ved selve grundlaget for disse elementer og buste nogle få myter om dem undervejs.
Lad os buste en myte, der er blevet gentaget ad nauseum om disse elementer: tanken om, at de er baseret på undersøgelser af, hvordan vi, web-samfundet, markerede vores dokumenter. Det er en myte, der er blevet gentaget i bøger, blogs og foredrag i årevis, og det er bare ikke sandt. Hvordan ved jeg? Jeg spurgte.
Da jeg undersøgte oprindelsen af disse elementer, besluttede jeg at spørge redaktøren af HTML5-specifikationen, Ian Hickson, hvor disse elementer kom fra. Han svarede:
Mig og andre WHATWG bidragsydere [tilføjet dem], [in] 2004ish, fordi de var klare elementer at tilføje efter at have set hvordan forfattere brugte HTML4. Vi senere (sent 2005 i begyndelsen af 2006) gjorde nogle objektive undersøgelser for at finde ud af, hvad de ti bedste HTML-klasser var, og det viste sig, at de stort set nøjagtigt matchede de elementer, vi havde tilføjet, hvilket var praktisk.
Lad os bryde det ned: For det første tilføjede Hickson og WHATWG medlemmerne disse elementer, før der blev foretaget nogen forskning . Du kan dykke ind i WHATWGs (heldigvis offentlige) postlistearkiver og opdage tidlige diskussioner om disse elementer for dig selv. For eksempel kan du se Hickson diskutere dem i november 2004 med kommentarer som f.eks denne :
Ja, jeg har til hensigt at inkludere ting som [semantiske elementer] i Web Apps. Whiteboardet på mit kontor har i øjeblikket en liste over elementer under overskriften "HTML5 BLOCK LEVEL ELEMENTS", og jeg forsøger at finde ud af, hvordan man får dem til at fungere godt (de pågældende elementer er i øjeblikket nævnt i udkastet, men udkastet overhovedet ikke håndterer overskrifter). Jeg har ikke set på inline markup endnu, men det er også på kortene.
Det ser ud til, hvordan HTML5 strukturelle semantikken kom til at være: en mand, en whiteboard og nogle input fra andre WHATWG medlemmer. (WHATWG, eller Web Hypertext Application Technology Working Group, blev dannet af browserrepræsentanter som svar på W3Cs opgave af HTML til det utopiske ideal for XHTML 2.0).
De elementer, der bruges af millioner af dokumenter, som vi har diskuteret og debatterede, syntes at være tilfældigt oprettet af HTML5-editoren i 2004. (Og blev mødt med en stiv kritik og nogle desværre præcise forudsigelser næsten straks.)
Tantek har i lange perioder insisteret på forsknings-før-specificere-nye formater i mikroformatets sammenhæng, og til sidst vil WHATWG-specifikationerne blive udformet med faktiske data, i stedet for at trække ting ud af vores kollektive behændinger. - Ian Hickson
Det bringer os til det andet punkt. I december 2005 - et år eller så efter at komme op med disse nye elementer - Hickson (en medarbejder hos Google) gjorde nogle undersøgelser af, hvordan dokumenter blev forfattet ved hjælp af Googles store dokumentdatabase. Undersøgelsen var 'en analyse af en stikprøve på lidt over en milliard dokumenter, udleder information om populære klassenavne, elementer, attributter og relaterede metadata.' ID'er blev ikke medtaget i undersøgelsen. Resultaterne blev offentliggjort af Google som Web Authoring Statistics (2005) .
Den kritiske del af forskningen, hvad angår HTML's strukturelle elementer, var den klasser resultater , som på trods af at bruge en prøve, hvor ~ 900 millioner af de 1 mia. dokumenter tilsyneladende slet ikke havde nogen klasser, indeholdt nogle fælles klasser. Jeg er sikker på, at vi alle har brugt i vores projekter før: fodbold, menu, titel, lille tekst , indhold, header, nav, copyright, knap, main, og så videre.
Hickson giver derefter sit spin på dataene, hvilket tyder på, at disse klasser "faktisk [kort] meget godt til de elementer, der foreslås i HTML5 'og giver en tabel, der sammenligner forskningsresultaterne og de nye elementer i HTML5: en footer klassen er i undersøgelsen, et footer element er i HTML5; en header klasse er i undersøgelsen, et header element er i HTML5; klasserne tekst , indhold , hoved , krop er i forskningen, og err ... artiklen er i HTML5, som vi ikke kan se, stemmer overens. afsnit findes ikke overhovedet, hvilket også er værd at bemærke.
Taget på pålydende værdi er dette alt rimeligt nok. Jeg bruger footer, du bruger footer, footer er i HTML5. Hvad er problemet?
Problemet er, hvis du læser det aktuelle HTML5 specifikation , elementerne i HTML5 er defineret på en måde, der ikke har lidt at gøre med, hvordan vi traditionelt har brugt dem.
På den ene side har Hickson introduceret et helt nyt koncept om strukturering af en webside i HTML5 med sektionselementer . På den anden side sammenligner Hickson sine HTML5 sektionselementer til klasser, der anvendes i naturen, uden at forstå, hvad de klasser faktisk blev brugt til. Et klassisk eksempel er 'header', som de fleste af os ville bruge til området øverst på siden, men HTML5-specifikationen antyder, at du kan bruge den til overskriften for hver kommentar på en side . Virkelig. Bare fordi klasser i forskningen og elementerne i HTML5 har samme navn, betyder det ikke, at deres anvendelser er de samme.
Nu, hvis det blev meddelt klart, at nye elementer blev introduceret med et nyt formål og en klar begrundelse, så ville det ikke være så dårligt. Men det er ikke det, vi har fået at vide.
Her er Hickson i 2009 , svar på et spørgsmål om formålet med sektion, nav, artikel, til side og andre:
De er mere eller mindre ved at udfylde de mest almindelige anmodninger fra webudviklere baseret på de mest almindelige klasse = "" attributværdier. Deres primære formål er at forenkle forfatter og styling.
Desværre synes dette at være et tilfælde, hvor HTML5-editoren, for alt hans gode arbejde i at trække spec sammen, har (lad os være generøse) glemt hvorfor han tilføjede disse elementer til hvad der i det væsentlige er hans spec. Måske er det tidsforskellen mellem 2009 og 2004, hvem ved det. Men vi ved det her: HTML5-sektionselementerne blev ikke tilføjet for at udfylde "de mest almindelige anmodninger fra webudviklere" overhovedet. Hvordan ved vi det? Vi kan bare se på listen, og se de mest grundlæggende elementer, der er tilføjet, såsom sektionselementet (og den relaterede artikel og sideelementer), vises ikke i de almindelige klassetributters forskning.
Selv om Hickson måske har glemt, hvorfor disse elementer blev tilføjet, kan vi stadig heldigvis læse den spec, der dokumenterer deres formål.
Men hvad sker der, når du fortæller webdesignere og udviklere ikke at bekymre dig, disse elementer erstatter bare det, du allerede laver, og derefter angiver disse elementer på en måde, der bestemt ikke er, hvad webdesignere og udviklere gjorde? Du sætter dem på en envejs tur til forvirringsby.
Dette er den værste slags forskning: En doven fortolkning af data udført for at retfærdiggøre beslutninger, der allerede blev truffet. Et ofte gentaget designprincip i HTML5 er at ' bane cowpaths ', det er' Når en praksis allerede er udbredt blandt forfattere, overveje at vedtage det snarere end at forbyde det eller opfinde noget nyt. ' Og så synes det med disse nye strukturelementer: sektion, artikel, nav og til side (og header og sidefod) - disse er bare "banebrytninger"?
Det er det indtryk, mange af os har, da det er det, vi har fået at vide, de er.
Faktisk for næsten fem år siden da vi først fik en preview af HTML5 , det så ud som om disse elementer simpelthen kunne erstatte de "usemantiske" divs, som vi var vant til at bruge. Hvad var div id = "header" øverst på siden kunne nu bare blive header ; div id = "footer" kunne nu bare blive footer , og vores div kunne bare være artiklen. Enkel, ikke?
Desværre har vi faktisk implementeret disse elementer på trods af det, vi fik at vide (dvs. bare bytte den ene ud for den anden) på en måde, der ikke afspejles i HTML5-specifikationen. Det er, når det kommer til HTML5 struktur, har vi hovedsageligt forked spec. Der er i øjeblikket to metoder til HTML5 struktur derude - samfundsfortolkningen, som afspejles i 2007 A List Apart-artiklen (og utallige andre); og den egentlige HTML5-specifikation, der introducerer en helt ny måde at strukturere en webside, der hedder omtalt.
Dette er modsætningen i hjertet af HTML's strukturelle semantik. På den ene side har vi redaktøren fortalt os, at de nye elementer er baseret på forskningen om, hvad vi allerede gjorde, og derfor har til formål at gøre forfatteren lidt lettere; og på den anden side har vi, hvad redaktøren faktisk skabte i HTML5-specifikationen, som er en ny måde at strukturere en webside på, som genererer en dokumentoversigt ved hjælp af sektionselementer .
Der var et klart valg at blive lavet her. Bryde med HTML5 design principperne og introducere noget nyt, eller blot følge ægte forfatterpraksis og specificere elementer på en måde, der afspejler webdesign praksis. Hickson forsøgte at gøre det første og kalde det sidstnævnte, og vi har nu et stort rod på vores hænder.
Sulten for mere? Del 2 af denne artikel er nu tilgængelig, og Lukas bog "The Truth About HTML5" er tilgængelig i et begrænset tidsrum gennem vores søsters websted MightyDeals.com med en fantastisk 50% rabat.
Arbejder du med HTML5 strukturelle elementer? Kan du finde dem nyttige, eller en hindring? Lad os vide i kommentarerne.
Fremhævet billede / miniaturebillede, anvendelser struktur billede via Shutterstock.