Om Martin
Martin liker
Semantisk vs. strukturell markup
17.10.07 • 5 kommentarer
Det snakkes mye om semantisk markup i webutviklermiljøet. Imidlertid er det nesten ingen som snakker om strukturell markup. Ofte ser vi til og med erfarne webutviklere omtaler strukturell markup som semantisk. Hva er egentlig forskjellen på semantisk og strukturell markup? Vet webutviklere forskjellen? Vet du forskjellen? Hvorfor trenger du å vite forskjellen? Er du usikker på svarene bør du lese videre.
Forskjellen er liten men viktig. For å forstå begrepene må vi tilbake til litteraturen og se på hva ordene betyr.
Semantikk
~tik’k -en (fra gr ‘betydningsvitenskap’, av sema ‘tegn’) vitenskapen om ordenes betydning.
Setter vi betydningen av ordet semantikk i sammenheng med markup, kan vi si at semantisk markup er elementer som markerer ordenes betydning i et SGML-dokument. Enklere forklart benytter vi semantisk markup til å markere tekst med hva som er overskrifter, avsnitt, fet tekst, kursiv tekst, med mer.
Struktur
struktu’r m1 (fra lat., av struere ‘bygge, ordne’)
1 måte som noe er satt sammen, bygd opp på (av ulike smådeler), oppbygning, sammensetning en bergart med krystallinsk s- / et atoms s- / atoms- / samfunnets s- / samfunnss- / et språks s- / språks-
2 geologisk lag ny s- i Nordsjøen som inneholder både olje og gass
I denne definisjonen finner jeg det interessant at man benytter ordene «satt sammen» og «lag». Setter vi betydningen av ordet struktur i sammenheng med markup, kan vi si at strukturell markup er elementer som markerer sammensetning eller lag i dokumentet. Eksempelvis benytter man strukturell markup til å sette sammen forskjellige deler av et SGML-dokument, som for eksempel meny, innhold og bunntekst.
Hvordan berører dette meg som webutvikler?
Du lurer garantert på hvordan dette berører deg som webutvikler. Hvorfor trenger du som utvikler for web å skille disse to begrepene fra hverandre?
Først og fremst fordi du som webutvikler bør ha et svært bevisst forhold til hvilke elementer — også kalt tagger — du putter inn i løsningene du produserer. Semantiske elementer blir tolket av både klienter og søkemotorer, og må ikke brukes uten at innholdet tilsier at du skal benytte et semantisk element. Strukturelle elementer kan du imidlertid pøse på med etter eget ønske, dersom du ser det som hensiktsmessig. Ulempen er selvfølgelig at koden blir vanskeligere å lese, samt tregere å laste.
I tillegg skiller man mellom semantisk og strukturell markup i arbeidsprosessen når man utvikler. Jeg kommer til å skrive mer om dette når jeg har noe mer å presentere om modellen jeg arbeider på, «Stratify».
5 kommentarer
-
Strukturell markup er for mange ekstra div-elementer. Det virker som om mange misforstår og ikke helt kobler at semantiske elementer også kan være strukturelle elementer. Personlig unngår jeg div-elementer så langt som mulig av prinsipp. Kan man bygge strukturen semantisk gjør man det i stedet for å pøse på med container-elementer.
-
I semantikkens verden — altså utenfor vår verden — er fet og kursiv presentasjon, eller typografi. Sånn sett kan man jo si at det meste av de semantiske elementene vi benytter blir presentasjon straks de kommer på papir, da de ikke gir noen verdi annet enn det visuelle. I denne sammenhengen faller derimot fet og kursiv under semantiske elementer. Jeg er litt usikker, men mener å huske at begge behandles spesielt av nettlesere for tilgjengelighetsbehov.
Du har et godt poeng i at semantiske elementer kan benyttes som om de var strukturelle elementer, Tormod. Bakgrunnen for dette ligger i forskjellen mellom de såkalte blokknivåelementene (block level) og linjeelementene (inline), ettersom semantiske elementer enten er blokknivå- eller linjeelementer. Eksempelvis kan man utforme menyer uten bruk av strukturelle elementer, men med listeelementet som utgangspunkt.
Når det gjelder unødvendig bruk av strukturelle elementer, er jeg helt enig i at det er et mål å bruke så få elementer som mulig. Argumentene for dette er som nevnt ryddig kode og lettere å laste. Utover dette finnes det ingen reelle argumenter for å la være å bruke strukturelle elementer.
Imidlertid er det slik at i den virkelige verden — hvor man ikke nødvendigvis skriver koden for hånd, men får den generert av en publiseringsløsning — vil det være hensiktsmessig å ha et eller flere sett strukturelle elementer å kunne benytte seg av når man skriver CSS, litt avhengig av tid og pris som er tilgjengelig i prosjektet. Er det nok tid og penger kan man selvfølgelig håndskrive malene fra bunnen av, slik at den genererte koden blir slik man selv ønsker, men det er ikke alltid nok ressurser til å gjøre det. Et godt eksempel på dette er markupen som er tilgjengelig for de som designer løsninger til CSS Zen Garden, hvor man har en lang rekke ubrukte elementer tilgjengelig.
I prosjekter hvor jeg selv har arbeidet, har vi implementert en fullverdig publiseringsløsning på to og en halv time, basert på standardmalene. Det sier seg selv at her er det tid og penger å spare.
-
Jeg sa jo at jeg spikket fliser her, og er glad for at det ser ut som om du så det.
Alle semantiske elementer blir presentasjon straks de kommer på papir, det er helt riktig – og en interessant observasjon. Men fordelen til vårt medium er jo nettopp det, at det ikke er papir, og vi derfor kan skille mellom presentasjon og semantikk.Fet og kursivert tekst merkes jo som kjent i HTML med taggene ‘b’ for ‘bold’ og ‘i’ for ‘italic’. Dette er egentlig kun presentasjonsinformasjon, det forteller hvordan bokstavene skal se ut. Jeg vil regne med at nettlesere behandler ‘i’ og ‘b’ spesielt, men det er vel egentlig kun for å ta høyde for den utstrakte feilbruken av disse elementene.
Det vi vil når vi bruker disse elementene, er jo egentlig å legge trykk på deler av teksten. Og det finnes det gode, semantiske elementer for (som riktignok også som regel presenteres som fet og kursivert), nemlig ‘strong’ og ‘em’.
Og selv om jeg altså innrømmer at jeg spikker fliser, vil jeg hevde at når man skal skrive fagstoff om semantikk, er det viktig å skille mellom uthevet tekst og bokstaver som står på skrå …
-
Flisespikking er en kunst du behersker til det fulle, vet jeg.
Jeg er helt enig i det du skriver, for det er jo riktig. Imidlertid må vi huske at vårt medium også kan trykkes papir, og det gjør det hele ekstra interessant. Da får elementer som «strong» og «em» både semantisk- og presentasjonsverdi. Det er nok derfor elementer for presentasjonsformål som regel omtales som sub-sett av semantiske elementer, i den grad man omtaler de i det hele tatt.
Poenget mitt er at det hovedsaklig kun snakkes om semantiske og strukturelle elementer, i den hensikt at man ønsker å skille de fra hverandre og ha fokus på når man bruker de. Poenget var altså ikke å diskutere elementene i seg selv, selv om det også er interessant.
Har du synspunkter? Legg igjen en kommentar!
RSS og trackback
Med RSS kan du abonnere på nye kommentarer som postes til denne artikkelen.
Du kan legge igjen et trackback fra ditt eget nettsted ved å benytte trackback-adressen til denne artikkelen. Eventuelle tracback ser du under.
Flere artikler
- Lightroom og metadata
- Holder de ord
- The Greatest Bits 3
- Røde kjemper
- Fremdrift
- Skydebatten
- Supertankere og robåter
- IT-realitetsorientering
- Altinn-skandalen
- Steve Jobs
Enda flere artikler? Besøk arkivet.
Bekkelund.net er en blogg av Martin Bekkelund, hvor han lufter sine tanker om IT og IT-politikk. Martin arbeider til daglig som seniorrådgiver, foredragsholder og skribent i IT-bransjen, hvor han veileder bedrifter og organisasjoner i strategisk bruk av IT. Les mer...
© 1995-2012 Martin Bekkelund
Opphavsrett • RSS • Kontakt
Lasse G. Dahl
17. oktober 2007 21.03
Hvis vi skal være pinlig nøyaktig, er vel “fet” og “kursiv” presentasjon og ikke semantikk?