Semantisk HTML - hvem bryr seg?
I “XHTML er mer enn <div>” skrev jeg litt om de forskjellige rollene XHTML, CSS og Javascript har, og viktigheten av å skille rollene. Å skille rollene mellom disse tre er noe jeg er veldig opptatt av, og en av grunnene til at man bør skrive semantisk HTML. For å se litt på akkurat hvorfor semantisk HTML er så viktig i denne sammenhengen, la oss se på hvordan man går frem for å skille lagene fra hverandre.
Design/CSS
På design-fronten er det første skrittet tatt idet man går bort fra å bruke tabeller til layout. Dette har grensesnittsprogrammerere og designere messet om i en del år allerede, og mange har tatt hintet (men for all del, det er mye å gå på enda, se feks www.stortinget.no, www.oslo.kommune.no, www.vg.no). Når man slutter å bruke tabeller (og annen formatterende markup, feks <font>, <b> osv) er det CSS som gjelder dersom man ønsker å ha et design på nettsidene sine.
Skritt to er dermed å se til at all CSS er samlet i eksterne filer som lenkes inn i HTML-dokumentet. På denne måten kan man også angi for hvilke media man ønsker at stilsettene skal brukes, og dermed også lage forskjellige stilark til forskjellige media - eksempelvis et for utskrift og et for skjerm (den vanligste kombinasjonen).
Oppførsel/Javascript
Et økende antall nettsteder bruker alt fra litt til MYE Javascript for å berike brukeropplevelsen. Skritt en for å skille oppførselen fra strukturen er enkelt å greit å samle all Javascript-kode i eksterne filer og linke disse inn i HTML-dokumentet. Skritt to er å rydde HTML-dokumentet fullstendig for Javascript-kode ved å fjerne “event handlers” (et godt norskt uttrykk her, noen?) Dette legger også grunnlaget for elegant bakoverkompampatibilitet og kompatibilitet med brukere som ikke har aktivert Javascript, eller har nettlesere som ikke støtter koden du har skrevet. (Mer: Unobtrusive Javascript.)
Semantisk HTML
Har du kommet deg gjennom de fire punktene over, er du langt på vei. Hvis du i tillegg har et HTML-dokument som validerer vil nok mange gi seg her og klappe seg selv fornøyd på skuldra. Vi har oppnådd et tydelig skille mellom de tre lagene samtidig som vi ikke har rørt selve HTMLen, og ikke har tenkt på semantikken i markupen.
Så hvorfor skal vi bry oss om å bruke riktige tagger til riktig innhold? Hvorfor skal vi tilstrebe å bruke <h1>-<h6> til overskriftene, hvorfor skal vi bruke et par minutter ekstra på å gi menyen vår et godt “navn” gjennom ID-attributtet, og hvorfor skal vi unngå å bruke <h2> for å få akkurat den font-størrelsen eller å skrive ting som class=”blueBox”?
Hvorfor?
Vi skal bry oss om dette fordi dette er skritt tre på stien til å rense innholdet vårt for design. Å bruke klassenavn som “blueBox” virker som en veldig god ide når man sitter og koder på et design og bestemmer seg for å lage gjenbrukbare komponenter. bluBox er et tydelig navn som sier hva dette er, og du vet hva du får når du tar det i bruk. Fleksibilitet er ofte en av grunnene til at man ender opp med slik klassifikasjon. Publiseringssystemet eller applikasjonen skal gi redaktørene så stor kontroll at man ender opp med elementer som er tett knyttet til designet sitt for å klare kravene.
Dette blir fort et problem allerede under utvikling, når designet en dag forandrer seg slik at de fleste “blueBox”ene du har plutselig er røde bokser. Skjer dette har du enten en ekstrajobb med å navngi alle boksene på nytt, eller et vedlikeholdsproblem. Et annet problem er at HTMLen ikke sier noe som helst om innholdet. Hvis innholdet i vår “blueBox” faktisk er en overskrift kan dette koste oss noen plasseringer i treffet på Google og andre søkemotorer.
Jeg begynte dette innlegget med å prate om skille av roller, og vi har nådd et nivå hvor veldig mange slutter å skille. Dersom man ikke fokuserer på innholdet og strukturen i det når man skriver HTML, VIL man garantert møte på probleme jeg nevner over. Ofte vil man også ende opp med et større navnerom (mange spesifikke navn) og dermed også muligens mer komplisert og repiterende CSS. Motsetningen er et mindre antall unike navn, og å heller benytte seg av kontekst for å implementere designet, tema for et helt annet innlegg.
Blå bokser, semantisk variant
For å ta vår “blueBox” fra tidligere en gang til. Hadde man fokusert på innholdet i disse istedenfor designet der og da ville man kanskje ha kommet frem til noe mer beskrivende som for eksempel “product”, eller “article”. Med disse navnene kan man fortsatt lage blå bokser, og det er ikke noe problem å farge dem røde ved et senere tidspunkt. I tillegg kan man skape et mangfold ved å stile boksene forskjellig etter hvilken tag som bruker navnet (for eksempel <li>, <div>), hierarkiet de står i (under en div med id=”content”, eller div med id=”navigation”) eller annet.
Som en tilleggsbonus er det større sjanser for at automatiske tjenester som leser tjenesten vår kan gjøre noe fornuftig med innholdet ( Google Products vil sannsynligvis sette større pris på boksen/seksjonen “product” enn blokken “blueBox”). Og for å være ærlig: det er da ikke mye mer jobb å tenke ut at noe er et produkt enn å tenke ut at noe er en blå boks er det vel?
Dette innlegget er desverre ekstra utsatt for spam, og inntil jeg har tid til å sette opp noe spambeskyttelse har jeg sett meg nødt til å stenge kommentarer for dette innlegget. Dine innspill er velkommen på de fleste andre innlegg!
Kommentarer
Trond
(http://www.topicobserver.com/blog/)
6. september, 14:56
Kan så være at det er et lurt prinsipp å gi ting meningsbærende navn — for sin egen del, akkurat som en programmerer kan gjøre lurt i å gi metodene sine beskrivende navn som getName() i stedet for xdw(), men ID-attributter har ingen innebygget mening ((X)HTML standarden) og er slik sett ikke semantiske. Deres verdier er bare IDer.
Altså kan en ikke snakke om semantisk HTML dersom alt en gjør er å tildele ID-attributter navn med betydning for mennesker. For nettlesere og andre klienter, inkl. søkemotorer, er det likegyldig hva disse attributtene inneholder. Semantisk HTML handler derimot om å benytte HTML-elementer på en korrekt måte, slik at deres innhold har den meningen den er ment å ha ut fra elementets semantikk (som nedfelt i standarden).
For øvrig viktige poenger med å skille HTML, CSS og JS fra hverandre og å bruke HTML korrekt. Hva gjelder sidene du peker til, velger jeg å tro at enkelte av dem nok benytter publiseringsverktøy/rammeverk som ikke produserer god HTML (rent bortsett fra at www.vg.no også skjærer i øyet). Dessverre finnes det mange eksempler på tunge systemer som ikke er gode på HTML (og som f.eks. skriver ut tabell-baserte sider).
Christian Johansen
(http://www.cjohansen.no)
7. september, 06:42
Dersom du bruker klasser og/eller IDer som er knyttet tett til designet ditt er ikke dokumentet ditt lengre kun et semantisk dokument - det er altså ikke et dokument som kun uttrykker elementenes mening, men også sier noe om elementenes utseende.
(X)HTML har et begrenset begrepsapparat (det finnes ikke beskrivende elementer til alt vi beskriver). Nettopp derfor er div og span en del av spesifikasjonen (http://www.w3.org/TR/html401/struct/global.html#h-7.5.4) - de gir forfattere en måte å tilføre dokumentet vilkårlig struktur. For at disse skal gi mening gir man dem class- og id-attributter som har sin egen semantikk.
Siden “semantisk HTML” hverken er en spesifikasjon eller et entydig definert begrep er det fullt mulig å si at div/span med semantiske klassenavn er en del av dette begrepet. Greit, du vil sannsynligvis ikke få direkte uttelling i noen av dagens søkemotorer - men hva med morgendagens søkemotorer? Hva med andre klienter så som bloggverktøyene til feks Technorati? Er det ikke sannsynlig at de på et tidspunkt til gjøre seg nytte av dette? Og hva med mikroformater? Dette er semantiske klassenavn satt i system.
Se forøvrig W3Cs "Use class with semantics in mind” - http://www.w3.org/QA/Tips/goodclassnames
Trond
(http://www.topicobserver.com/blog/)
7. september, 18:36
Vel, jeg vil påstå at Semantisk HTML bare betyr å bruke de strukturelle elementene som de var ment, da HTML kun har semantikk innenfor konteksten av layout. Å beskrive *innholdet* i et HTML-dokument vha. meningsbærende klassenavn (for mennesker), som ikke har noen nedfelt semantikk via standarden, vil jeg ikke si gir Semantisk HTML som sådan.
Semantikken det her er snakk om eksisterer bare i forfatterens hode — HTMLen blir ikke mer meningsbærende enn hva den er fra før (nettopp fordi standarden definerer disse elementene som “meningsløse” og ikke legger føringer på verdiene — noe vi kan være glade for). Men som du sier kan kanskje dette være et definisjonsspørsmål.
Du har dog selvsagt rett i at det er lurt å bruke fornuftige klassenavn, slik W3C også anbefaler, ja.
“Greit, du vil sannsynligvis ikke få direkte uttelling i noen av dagens søkemotorer - men hva med morgendagens søkemotorer?”
Jeg tror ikke morgendagens søkemotor kan slutte seg til at class=”products” betyr hva en forfatter legger i konseptet “products” / hva “products” “er” — eller hva det kan være. Derfor kan den heller ikke “vite” hva innholdet i en div er, gitt verdien av et tilfeldig attributt. Her har i det minste teknologier som emnekart og RDF mer for seg, enn å forsøke å beskrive innholdet direkte i HTML vha. attributter.
Uten å ha satt meg inn i mikroformatene som finnes: Hva gjelder “formater” som f.eks. XFN, mener jeg de ikke tilfører mye, da en bare forsøker å utvide HTML med “elementer” som beveger seg utenom det domenet HTML beskriver / er ment å beskrive. Teknologier som RDF er sannsynligvis bedre egnet for slike formål.
Trond
(http://blog.topicobserver.com)
7. september, 18:40
Det betyr selvsagt ikke at det ikke er lurt å bruke klassenavn som gir mening for utviklere, men er bare en avsporing fra temaet i retning av “…dersom en ønsket at…”, “jeg kverulerer over temaet `semantikk’”… :)
Christian
(http://www.cjohansen.no)
9. september, 11:01
Kommentarer er stengt