I den første delen av denne serien vi dekket feilene som fører til HTML5s strukturelle elementer, i denne andre delen vil vi se nærmere på konsekvensene av disse feilene.
Jeg har sagt flere ganger at HTML5 introduserer en ny metode for strukturering av en nettside, og du lurer nok på hva det egentlig er. Det er der i spesifikasjonen, hvilken introduserer konseptet av "seksjonsinnhold ': Innsnittsinnhold er innhold som definerer omfanget av overskrifter og bunntekster. Hvert seksjonsinnholdselement har potensielt en overskrift og en oversikt.
Spesifikasjonen dokumenterer sin tilnærming til overskrifter, seksjoner og skisser for å gjøre konseptet klart. Vel, klart for de som må implementere funksjonaliteten i nettlesere. For at vi skal forstå HTMLs strukturelle elementer (seksjon, artikkel, nav, til side og tilhørende elementer header og footer) og dette obskure konseptet om "sectioning content" eller "outlining", må vi ta en liten tur gjennom HTML-historikken.
Konseptet med skissering introdusert i HTML5 kan spores tilbake så langt som 1991, og ble inkludert i den forvirrede, avsluttende XHTML 2.0-spesifikasjonen, og til slutt ser dagens lys i HTML5 ... bare for å være så dårlig kommunisert at ideen er ganske mye død ved ankomst.
Før HTML5 ble den hierarkiske strukturen til en side bestemt av overskriftselementene - våre gamle venner h1 til h6. Vi kunne strukturere en side ved å si at siden tittelen er h1, artikkelen overskriften kan være h2, og kanskje underposisjoner i artikkelen kan være h3 og h4, og så videre.
Dette er greit for et enkelt dokument, men bruk av overskriftskoder for å lage et logisk hierarki, eller "dokumentoversikt", for en kompleks, moderne nettside er svært vanskelig. En del av problemet er mangelen på en måte å bestemme hvor en sideseksjon starter og stopper. For eksempel, si at vi hadde vårt tidligere nevnte dokument med h1 for sidetittelen, h2 for artikkeltittelen, h3 for underrubrikkene, men så ønsket å markere tittelen for våre sidebjeldseksjoner med h3 overskrifter også.
Dokumentoversikten slik en struktur ville skape, ville se noe slik ut:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Her eies h3-elementene av h2 over dem, selv om det ikke gir mye mening. Selvfølgelig vil vi bryte disse opp med noe som div for artikkelen, og div for sidebaret, men disse blir ignorert av brukeragenter (for eksempel skjermlesere) som bestemmer sideoversikten ved å skrive strukturen alene.
Ved å knytte sidehierarki direkte til det som ofte er presentasjonsoverskriftsnivåer, er vi begrenset til hvordan vi kan strukturere en side.
I et forsøk på å løse dette problemet introduserer HTML5 begrepet "delingselementer", det vil si spesielle elementer som deler siden opp i - du gjettet det - seksjoner, og disse delene bestemmer nestingsnivået for overskrifter og faktisk hierarkiet , eller "disposisjon" av siden.
Det vil si at hierarkiet av siden er koblet fra overskriftelementene, og i stedet bestemmer disse nye delingselementene hvilket nivå et overskriftselement faktisk er.
I det første utkastet XHTML 2.0 spesifikasjon , snittarbeid arbeidet med et snittelement og et generisk header h-element. Når vi skriver HTML, vil vi ikke spesifisere hvilket nivå av overskrift vi ønsket å bruke, vi ville bare la nettleseren avgjøre nivået på nesting for en bestemt overskrift. Vi kunne hekse delelementer 99 nivåer dypt, og et h-element på 99-nivået ville tilsvare et h99-element. På den måten kan vi strukturere dokumentene våre logisk, uten å bekymre oss for hvordan vi kan bruke de begrensede h1-h6-elementene.
(Denne ideen går egentlig tilbake til 1991, forresten: som Jeremy Keith påpekte, Tim Berners-Lee mente ideen om en seksjon og h element for å strukturere en side på slutten av denne oktober 1991 e-post .)
Hickson forsøkte å introdusere det samme konseptet i HTML5, men med en ekstra vanskelighetsgrad: han ønsket å opprettholde bakoverkompatibilitet, og introdusere noen nye semantikk for å forenkle forfatterskap for å starte opp. Derfor, i stedet for bare å ha et seksjonselement i HTML5, har vi også en artikkel, nav og sideelement som alle gjør det samme som seksjon, men med forskjellige navn, som skal brukes på forskjellige måter.
Hva sier spesifikasjonen om disse elementene? Jeg oppfordrer deg til les spesifikasjonen for deg selv , men her er en smak:
Seksjonselementet er grunnlaget for seksjonering for å lage et dokumentoversikt.
Delelementet representerer en generisk del av et dokument eller en applikasjon. En seksjon, i denne sammenheng, er en tematisk gruppering av innhold, typisk med en overskrift.
Eksempler på seksjoner vil være kapitler, de ulike fanebladene i en tabbed dialogboks eller de nummererte delene av en avhandling. Et nettsteds hjemmeside kan deles inn i seksjoner for en introduksjon, nyhetsartikler og kontaktinformasjon.
Et notat i spesifikasjonen sier at elementet ikke bør brukes til rent styling formål - en div ville være bedre der, og forståelig nok, slik at seksjoner som kastes i vilje for styling, ville skape en meget ødelagt dokumentoversikt.
Notatet fortsetter å si 'En generell regel er at seksjonselementet bare er hensiktsmessig dersom elementets innhold vil bli oppført eksplisitt i dokumentets disposisjon' og det er den klareste erklæringen om seksjonselementet i spesifikasjonen.
Når vi forstår begrepet snitt og skissering, er inkluderingen av seksjonselementet fornuftig. Det viste seg ikke i den felles klassen verdier forskning, men det ble vist i XHTML 2.0, og går tilbake konseptuelt til 1991.
De andre strukturelle elementene HTML5 introduserer - de som tilsynelatende gjenspeiles i forskningen - gjør nøyaktig det samme som delelementet, så langt som dokumentoversikten angår. De lager også hierarkiet til siden, og dermed dokumentets disposisjon.
Ta artikkelen elementet for eksempel. Mange antar at det bare er for artikler som denne. Men det er det ikke i det hele tatt. Det er "artikkel" i den forstanden at det er "en klærartikel". Det er bedre tenkt på som «gjenstand» som i «et klær», da dets definisjon er så bred.
Når artikkelelementer er nestet, representerer de indre artikkelen elementene som i prinsippet er relatert til innholdet i den ytre artikkelen. En bloggoppføring på et nettsted som aksepterer brukerinnleverte kommentarer, kan for eksempel representere kommentarene som artikkelelementer som er nestet i artikkelen for blogginnlegget.
I HTML5 er brukerkommentarer, artikkelen riktig, foruminnlegg, og til og med "interaktive widgets og gadgets" alle artikler. Definisjonen er så bred at den er ubrukelig - semantikken skal gi mening, men ved å bruke et kollektivt uttrykk for et så bredt utvalg av elementer blir elementet meningsløst.
Dette er et eksempel hvor vi har forkedet spesifikasjonen. Noen følger folket riktig og gjør nesten alt en artikkel (blogginnlegg, blogginnlegg, kommentarer, widgets, foruminnlegg, etc.), mens andre har holdt det bare for hovedartikkelen på en side, som bare er en del av den brede definisjonen. Du kan tenke det spiller ingen rolle på noen måte, og i stor grad ville du være riktig. Men tenk på alle de lesetjenestene som tar sikte på å bare analysere hovedinnholdet på siden. Hvilken implementering av spesifikasjonen skal de følge? Bør de følge hva spesifikasjonen faktisk sier, eller skal de følge det generelle samfunnet gjennomføring der det vanligvis er bare en kanonisk "artikkel" på en side?
Dette er en savnet mulighet, og hva skjer når spesifikasjonen ikke klarer å spesifisere , og redaktøren og for å være rettferdig, fellesskapet, mislykkes i å kommunisere hva spesifikasjonen faktisk sier.
Tenk deg om artikkelen ikke ble brukt til kommentarer. Tenk deg om kommentarer fikk sitt eget element, for eksempel, og adopsjonen ble utbredt. Nettleser beslutningstakere kan legge til en "mute comments" -funksjon som enkelt kan skjule (eller på annen måte parse) kommentarer på nettsider. Men Hickson har spesifikt nektet en forespørsel om et kommentarelement . I HTML5 er det artikler helt ned.
Bortsett fra er et annet element som ikke forekommer hvor som helst i Hicksons klassenavnforskning, og får en veldig spesiell definisjon for oppstart:
Bortsettelementet representerer en del av en side som består av innhold som er tangentielt relatert til innholdet rundt bortsettelementet, og som kan betraktes som skilt fra det aktuelle innholdet. Slike deler er ofte representert som sidebjørker i trykt typografi.
Elementet kan brukes til typografiske effekter som å trekke sitater eller sidebarer, for annonsering, for grupper av navelementer, og for annet innhold som anses å være skilt fra hovedinnholdet på siden.
Hvem vet hvorfor til side bør dekke både pull quotes, sidebars, annonsering og grupper av navigasjonselementer, men det oppretter også nye seksjoner i dokumentoversikten. Dette betyr at trekkkuponger får sitt eget punkt i dokumentoversikten, som synes, la oss si "merkelig". Igjen har den tilfeldige bruken av velmenende webdesignere og vil skape mange brutte dokumentutskrifter.
Nav-elementet virker mest selvforklarende for delingselementene, og heldigvis har definisjonen ikke blitt strukket utover å bryte.
Nav-elementet representerer en del av en side som kobler til andre sider eller til deler på siden: et avsnitt med navigasjonskoblinger.
Som er bra, og kan ha teoretiske tilgjengelighetsfordeler (en brukeragent kan hoppe over, eller hoppe til nav-linkene - de gjør det ikke, men de kan).
Problemet er at i ånden av "forenkling av forfatterskap" og erstatning av div med nav-elementet, blåser vi opp navigasjons styling for en annen delmengde av brukere. Brukere av IE6-8 med JavaScript av (Yahoo's forskning tyder på 1-2% av alle brukere har JavaScript av ) er ofre for dette problemet. Med JavaScript av, fungerer ikke JavaScript-basert HTML5-shim som hjelper IE6-8 til å forstå HTML5-elementer, slik at nettleseren ikke stiler HTML5-elementer. Dette kan bare påvirke et lite antall brukere, men hvorfor påvirker de i det hele tatt?
Hoved- og bunntekstelementene er et klassisk tilfelle av å ta vanlige betingelser og gi dem svært forskjellige bruksområder.
Spesifikasjonen angir at ingen av disse elementene oppretter nye seksjoner i dokumentoversikten, til tross for at de ofte er avbildet som på linje med seksjon, nav, artikkel og til side. Faktisk gjør de ikke noe i det hele tatt. De er bare inkludert for å avgrense områder av en bestemt del i dokumentoversikten.
Her er hva spesifikasjonen sier om header: headerelementet representerer en gruppe innledende eller navigasjonshjelpemidler.
Merk: Et headerelement er ment å vanligvis inneholde seksjonens overskrift (et h1-h6-element eller et hgroup-element), men dette er ikke nødvendig. Overskriftselementet kan også brukes til å pakke inn en seksjons innholdsfortegnelse, et søkeskjema eller relevante logoer.
og bunntekst: bunntekstelementet representerer en bunntekst for sitt nærmeste forfedersnittinnhold eller snittrotelement. En bunntekst inneholder vanligvis informasjon om sin seksjon som for eksempel hvem som skrev det, koblinger til relaterte dokumenter, opphavsrettsdata og lignende.
I HTML5 er kroppselementet faktisk rotseksjonen, så en overordnet overskrift og bunntekst er ment å beskrive hovedlegemet. Enhver seksjon kan ha en header og / eller en footer-de er ikke ment bare for generelle overskrifter og footers, som vi kanskje har antatt. Individuelle kommentarer kan hver for eksempel ha en header og en bunntekst. Faktisk, som vi berørte tidligere, gir spesifikasjonen faktisk et eksempel på bunntekst som brukes i en kommentar over selve kommentarinnholdet. Det er riktig, i HTML5 kommentarer er artikler, og de kan ha en bunntekst for en overskrift, og det er i selve beskrivelsen. Ønsket du et bunntekstelement for overskriften til kommentarene dine? Nei? Vel, du har en.
Igjen, dette er hvor HTML5 tar vanlige termer, og bruker dem på måter som ikke er gjenkjennelige for den vanlige nettforfatteren.
Men det er noe vi ikke har sett på i HTML-implementeringen av seksjonering. Så du på det? Vi har snittelementene, men vi har ikke et generisk h-element. Ikke bekymre deg, løsningen er i spesifikasjonen :
Seksjoner kan inneholde overskrifter av hvilken som helst rang, men forfattere oppfordres sterkt til enten å bruke bare h1-elementer eller å bruke elementer av riktig rangering for seksjonens nestingsnivå.
HTML5 ønsker å være bakoverkompatibel, så WHATWG bestemte seg for ikke å introdusere et h-element (til tross for innføring av en haug med nye seksjonselementer), og i stedet ønsker å omforme h1-elementet til å være det generiske h-elementet. Bruk h1 overalt, og la HTML5 skisserealgoritmen bestemme sitt sanne nivå ... eller så går teorien.
Dette er en forferdelig ide av flere grunner, de to viktigste er tilgjengelighet og styling.
Å bruke h1 overalt er veldig dårlig for tilgjengelighet. Blindbrukere stole tungt på overskriftsstrukturen på et nettsted. Det er viktig for oss alle å bli påminnet om hvor viktig hovedstruktur er for tilgjengelighet. For eksempel, en desember 2008 undersøkelse av over 1000 skjermlesere brukere utført av WebAIM fant at 76% av blinde og synshemmede brukere alltid eller ofte navigerte etter overskrifter når de var tilgjengelige. Og en mai 2012-undersøkelse fant at 82,1% overskriftsnivåene var "veldig nyttige" eller "noe nyttige" når du navigerer på en nettside. (Dette er bra, praktisk forskning, så ta notat.)
Å ha h1s overalt vil gjøre nettsteder vanskeligere å navigere for blinde brukere. I teorien vil skjermlesere bruke HTML-oversikten algoritmen i stedet og navigere ved hjelp av dokumentoversikten, men i henhold til hvordan forfattere har blitt fortalt å implementere snittelementer, er skissering et rot og forsøke å navigere dokumentoversikt som ikke har blitt gitt noe som helst være enda verre for blinde brukere.
HTML5-spesifikasjonen gir en vei ut: Fortsett å bruke de riktige h1-h6-nivåene for å opprettholde bakoverkompatibilitet. Men nå opprettholder vi to dokumentutskrifter i det ene dokumentet, og med tanke på de problemene som forfatterne har hatt i selv vurderer dokumentoversikten i utgangspunktet, sannsynligheten for at noen opprettholder både en logisk h1-h6-oversikt og et logisk, riktig -Seksjonert HTML5-oversikt virker fjernt, i beste fall.
Men det blir verre. La oss si at vi vil kjøre med en ren HTML5-oversikt, og vi bruker h1s overalt. Husk, i HTML5-spesifikasjonen er h1 bare et generisk h-element; dets virkelige nivå bestemmes av hvor dypt det er nestet i snittelementer.
Så hvordan stiler vi det? Vel, vi kan legge klassenavn til alle våre h1-elementer slik at vi kan plukke dem ut, men det er i strid med det angitte HTML5-målet for å forenkle forfatteren. og vi kan like godt holde fast ved h1-h6 (alle er behandlet som generiske h-elementer i en HTML5-oversikt).
Vi kunne prøve og stilte dem gjennom kaskaden, men dette blir raskt absurd, som Nicole Sullivan har påpekt . Faktisk begynner "absurd" bare å beskrive den. Når du vurderer de mulige kombinasjonene av seksjon, artikkel, nav og til side, og du vil lage en generisk stil for en overskrift som er fem nivåer dypt (dvs. tilsvarende h5), må du skrive stiler for alle mulige kombinasjoner, som får helt latterlig . Her er generisk stil for et 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 er hva HTMLs strukturelle elementer gir oss. For et rot.
Sulten for mer? Del tre 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.
Bruker du artikkelelementer flere ganger i et dokument? Er seksjoner nyttige eller skal vi holde fast med divs? Gi oss beskjed om dine tanker i kommentarene.
Utvalgt bilde / miniatyrbilde, bruk struktur bilde via Shutterstock.