I den første delen av denne serien vi så på feilene som fører til strukturelle elementer som er nye for HTML5; i den andre delen av serien vi så nærmere på konsekvensene av disse feilene; I denne siste delen vil vi se etter en vei fremover, og trekke noen konklusjoner om dagens situasjon.
Dette er ikke et abstrakt problem: folk må faktisk lære disse tingene. Den neste generasjonen av webdesignere og utviklere vil bli lært med HTML5 som utgangspunkt. Jeg føler meg lei meg for den som må prøve og forklare skissering og deling av nåværende og fremtidige avlinger av studenter. Kanskje de klokt holder seg til det enkle formatet vi har som fortsatt fungerer bra: bruk divs med enten ID eller klasser.
Det er rimelig å foreslå at kanskje brukeragenter i fremtiden, for eksempel nettlesere og skjermlesere, vil gjøre mer med HTML5s strukturelle elementer, og det vil gjøre dem mer velsmakende for oss som forfattere.
Operaens Bruce Lawson foreslo akkurat det på WHATWG mailingliste i 2009 :
Tross alt vet jeg om ingen brukeragenter som kan bruke tid, seksjon, bunntekst, datagrid osv, men vi regner for det meste med å være snart.
Og her er hva Hickson, HTML5-redaktøren, sa som svar:
Jeg gjør ikke. De fleste av de nye elementene er bare ment å gjøre styling enklere, slik at vi ikke trenger å bruke klasser.
Alt dette, og redaktøren ser ikke brukeragenter noen gang selv bruker disse elementene. De er der, sier han, for å redde oss fra å bruke klasser. På en annen måte virker skaperen av disse elementene usikre på hvorfor de er til og med i spesifikasjonen, unngå å gjøre styling lettere.
Det er en tankegang som sier at vi bare trenger en håndfull ny semantikk uansett. Tross alt vil spesifikasjonen bli oppblåst hvis det var flere eller flere hundre flere nye vilkår lagt til.
Den ene hånden, jeg er enig. Når det gjelder å strukturere en grunnleggende nettside, vil jeg si at vi ville være bedre uten HTML-snittelementene helt. Hva var en gang en grei øvelse i å bruke divs har blitt et komplisert rot i HTML5 uten nettforsterkning.
Men når det gjelder semantikk generelt, er det tilfeller der mer mening kan legges på toppen av strukturen på vår nettside (det være seg HTML4, 5 eller hva som helst som kommer neste) ved å bruke flere attributter på våre eksisterende elementer.
En av de enkleste ting å implementere på et eksisterende eller nytt nettsted er ARIA landemerker. (ARIA står for tilgjengelige Rich Internet Applications og er en spesifikasjon som definerer en måte å gjøre webapplikasjoner og websider mer tilgjengelige.)
ARIA landemerker er en del av den generelle ARIA-spesifikasjonen, og en enkel type metadata som gjør det mulig for blinde og synshemmede brukere med skjermlesere å hoppe rundt til de betydelige delene av en side, dvs. "landemerkene". Vi legger bare til roll = "landemerke-navn" til et eksisterende element, på samme måte som vi vil legge til klasse = "klassenavn" til et element. AIRA landemerker er diskutert i forhold til HTML5 her .
ARIA landemerker er en mye bedre kamp for hva vi gjør for øyeblikket. Navngivningen er litt wonky, men i det minste reflekterer de den faktiske webforfatterøvelsen. For eksempel kan vi bruke:
(Husk at banner-, hoved- og innholdsinformasjon bare skal brukes én gang per dokument.)
ARIA landemerker er en enkel løsning som forbedrer navigeringsalternativer for brukerne av skjermlesere, uten å vade inn i det mørke området av HTML-dokumentet. De er raske og enkle å implementere, og bør virkelig være en del av din grunnleggende HTML-prosjektmal.
Så vi har mer semantikk for tilgjengelighet, men vi har også mer semantikk tilgjengelig for søkemotorer også.
Først må jeg være helt klar over at HTML5-elementene ikke har noen fordel for SEO overhodet. Det er en myte, og vi må legge den til sengs. Bruke en artikkel kode vil ikke hjelpe deg eller din klient rangere høyere enn den neste fyren. Du kan stole på at Google har funnet ut hvordan du finner og rangerer innholdet ditt nå.
Imidlertid er søkemotorer opptatt av å forstå hvordan det beste å vise (merk: ikke rangere ) webinnhold på en mer strukturert måte.
Derfor har de store søkemotorene gjennom årene fremlagt eller vedtatt eksisterende standardveier for å oppsummere strukturerte data på en nettside slik at de kan trekke ut den riktige informasjonen. For eksempel, når du søker etter vurderinger som du kanskje har lagt merke til, vises stjerneklassifiseringer i de beste Google-resultatene. Dette er et tilfelle at søkemotorer kan trekke ut poengsummen på en standardisert måte, og forbedre visningen av resultatene. Oppskrifter er et annet eksempel, hvor tilberedningstiden er oppført for hvert resultat. Selv om slike data ikke forbedrer et nettsteds rang, kan det mer detaljerte resultatet oppmuntre flere brukere til å klikke gjennom, så det er noen potensiell fordel der for et nettsted, og det er ofte nødvendig i en våpenløpssituasjon der alle dine konkurrenter gjør det uansett.
Selv om denne typen rike data har eksistert en stund i forskjellige guiser, bare i fjor de store søkemotorene lanserte et stort nytt utvalg av standarder for denne typen strukturerte data. De kaller dem "skjemaer", og de er plassert på Schema.org . De bruker HTMLs mikrodata standard, og har allerede blitt implementert av slike som eBay, IMDB, Rotten Tomatoes og mer.
Dette er det største spranget mot en mer semantisk web i år, og likevel ble det gjort bak lukkede dører med liten fanfare og ingen standardprosess overhodet. Det ble tapt på oss uten advarsel, og har siden det meste fløyet under webdesign fellesskapets radar. Det er mye overlapping med HTML5 semantikk også, for eksempel er det skjemaer for artikler , web sider og web sideelementer , blant langt flere skjemaer som inkluderer alt fra TV-episoder til medisinsk tilstand . Det er også anbefalt måte å beskrive videoer på nettet.
Etter all debatten om HTML's semantikk (og mangel på det), har søkemotorene gjort det klart at de vil ha langt flere semantiske data i vårt oppslag, men det kommer til å skje på toppen av eksisterende strukturer, og ikke med nye elementer.
Men sikkert for oss som et samfunn som er interessert i semantikk og webstandarder, er heller ikke HTMLs begrensede, feilstilte tilnærming til semantikk, eller den lukkede, bortkastede tilgangen til de store søkemotorene den beste veien fremover.
I noen sanser har HTML5 semantikkhesten boltet; Det er bare opp til oss å inneholde skaden. Når det gjelder schema.org, er det en helt ny verden, og en vi bør undersøke svært tett, eller en annen liten gruppe skal bestemme hva som er i våre - og nettets - beste interesser for oss. Faktisk kan det allerede ha skjedd.
La oss pakke inn med noen konklusjoner.
Det er mange gode deler i HTML5-spesifikasjonen, fra nye skjemafunksjoner til History API og Canvas implementering. Faktisk, uten WHATWG, som har vært drivkraften bak HTML5, ville vi fortsatt ha sittende fast med HTML4 / XHTML 1.0 mens vi ventet på W3C for å få sin handling sammen. Likevel, bare fordi HTML5 og all relatert teknologi rundt den er ny og spennende, betyr det ikke at vi må akseptere alt vi får.
Noen ganger er det verdt å se hvordan HTML-pølsen er laget, så vi vet hva vi spiser. Og i tilfelle av HTML-strukturelle semantikk, vil jeg heller passere.
Sulten for mer? Luke's bok "The Truth About HTML5" er tilgjengelig i begrenset tid gjennom søstersiden vår MightyDeals.com på en fantastisk 50% rabatt.
Har du brukt ARIA landemerker eller Schema.org? Ser du en fremtid for HTML5s strukturelle elementer? Gi oss beskjed i kommentarene.
Utvalgt bilde / miniatyrbilde, bruk struktur bilde via Shutterstock.