Snakk med Sverkeli
10 Ã¥r etter innføringen av CSS, er det fortsatt sørgelig mange webutviklere som ikke har peiling pÃ¥ det som kalles for “semantikk” i HTML. Dyre byrÃ¥er leverer løsninger som hører hjemme pÃ¥ skraphaugen hvis en Ã¥pner panseret. Det som for deg som vanlig bruker fremstÃ¥r som en fin og ryddig webside, kan i virkeligheten være tilnærmet katastrofalt dÃ¥rlig konstruert. I en artikkelserie kalt “Webskolen” vil jeg gi deg mine rÃ¥d om hvordan du lager websider som følger webstandardene og er tilgjengelige og brukervennlige. Først vil jeg altsÃ¥ ta for meg prinsippene for semantsik HTML.
Hovedprinsippen for semantisk HTML-kode er relativt enkle. For det meste handler det om å følge W3C sine anbefalinger. Den gjeldende anbefalte doctype, eller HTML-versjon om du vil, heter XHTML 1.0, og den kommer i tre ulike versjoner, transitional, framset og strict. Jeg vil i denne artikkelserien ta utgangspunkt i den versjonen som heter strict. Det blir for kronglete å gå inn på de store diskusjoner om valg av doctype her, men spesielt interesserte kan lese om det på A List Apart.
I dette kapittelet tar jeg kun for meg selve innholdet i dokumentet, altså det som ligger mellom <body> og </body>. Spesifikasjonene for doctype og alt som hører hjemme mellom <head> og </head> er et kapittel for seg, og vil bli tatt opp senere i serien.
HTML-koden skal være velformet. Det betyr at alle tagger skal lukkes, og de skal lukkes i samme rekkefølge som de ble åpnet. Hvis man har tekst som både er fet og i kursiv, skal koden være sånn: <strong><em>teksten</em></strong>. Den skal ikke være sånn: <strong><em>teksten</strong></em>. Tagger som står alene, skal også lukkes, altså <br/> og ikke <br>.
HTML står for Hypertext Markup Language. Det betyr at HTML er til for å strukturere hypertekst, altså et dokument som er tilgengelig på internet. Det er ikke laget for å bestemme utseendet. Alle som bruker Word tekstbehandling er vant med å bruke stilgallerier, slik at alle overskrifter formateres likt, og ved å endre på stilen endrer man også alle overskriftene samtidig. Det sammen gjelder for hypertekst. Man skal ikke ha noen former for stilattributter i koden, bortsett fra høyde og bredde på bilder og andre objekter. Vi bruker CSS til å bestemme hvordan tingene skal se ut. I den grad det er praktisk mulig gjøres dette i et eksternt stilark, der spesifikasjonene markes med id- og klassenavn som korresponderer med elementene i HTML-koden.
Alle elementer skal være markert med riktige tagger i forhold til innholdet, altsÃ¥ koder som gir semantisk mening. En overskrift markeres med taggene <h1>, <h2> … </h6> avhengig av hvilket nivÃ¥ pÃ¥ siden man er. Vanlige tekstavsnitt markeres med <p>, en horisontal strek med <hr/> adresseinformasjon med <address>, forkortelser med <abbr> osv osv. Jeg vil i tur og orden ta for meg de ulike elementene i de pÃ¥følgende artikler i denne serien. I mellomtiden anbefaler jeg w3schools og htmldog.
Man skal ikke ha overflødige og utdaterte koder. Vi skiller mellom tagger og attributter. Utgåtte tagger er applet, basefont, blackface, center, dir, font, i, isindex, layer, menu, noembed, s, shadow og strike. Utgåtte attributter er alink, align, background, border, color, compact, face, height*, language, link, name, noshade, nowrap, size, start, text, type, value, version, vlink og width*.
*) Width og height er fortsatt gyldig, og anbefalt, i enkelte tilfeller. Det brukes for bilder, flash og video, for å rydde plass til disse elementene ved rendring av siden før elementene er lastet.
De vanligste elementene som du bør beherske er div, p, br, ht, h1, h2 … h6, abbr, acronym, address, cite, ul, ol, li, a, img, span, table tr, td, embed, object, strong, og em. Det finnes flere, men dette er de vanligste, og som du kommer veldig langt med. Du vil behøve flere tagger nÃ¥r du begir deg ut pÃ¥ bruk av f.eks. skjemaer der brukeren blir bedt om Ã¥ fylle inn f.eks. gjestebokinnlegg, eller som her, kommentarer til artikkelen. For full oversikt, sjekk ut HTML Dog.
Før CSS ble introdusert var tabeller den eneste mÃ¥ten Ã¥ ordne innholdet pÃ¥ en side i kolonner og rader pÃ¥. Dette skal du straks slutte med dersom du fortsatt holder pÃ¥ med det. Tabeller er et nyttig verktøy til organisering av innhold som det er naturlig Ã¥ utliste tabulært, som f.eks. adresselister og resultater fra idrettskonkuranser og budsjetter. Det er ikke naturlig Ã¥ bruke det til Ã¥ organisere webisders layout. Til layout markerer vi hvert element med en logisk tag, og bruker sÃ¥ CSS til Ã¥ bestemme elementets plassering, høyde, bredde, tekstformater osv. Jeg vil anbefale deg til Ã¥ lese gjennom “Why tables for layout is stupid: problems defined, solutions offered “.
Elementene skal komme i den rekkefølgen de ville hatt dersom de var f.eks. skrevet som en bok. Dette kalles elementets flyt, eller “flow” pÃ¥ utenlandsk. I en bok kommer for eksempel innholdfortegnelsen før innholdet. PÃ¥ samme mÃ¥te skal menyen pÃ¥ en webside komme først i dokumentet. Dersom man ønsker Ã¥ plassere den visuelt et annet sted, sÃ¥ kan man gjøre det med CSS, ved Ã¥ bruke float eller position for Ã¥ frigjøre elementene fra dets naturlige posisjon i dokumentets flyt.
Hvis du bruker Opera som nettleser, kan du ved Ã¥ klikke pÃ¥ “Forfattermodus” eller “Author mode” skru av stilarket og se hvordan dokumentet ser ut uten styling. Det bør da være logisk oppbygd fra topp til bunn. Det er slik dokumentet vil se ut i f.eks. en mobiltelefon.
NÃ¥r du har lagt inn alt du har av innhold, og utstyrt det med de nødvendige taggene, bør du sjekke at det er korrekt i henhold til standardene. Vi kaller dette Ã¥ validere koden. Til dette benytter du W3C sin validator, som du finner pÃ¥ http://validator.w3.org/. I Opera kan du høyreklikke pÃ¥ siden og velge “Kontroller kildekode” og siden vil da automatisk lastes opp i validatoren.
Har du spørsmål, kommentarer eller innspill så er det helt supert. Fyll ut skjemaet nedenfor her, så lover jeg å svare. For generelle spørsmål angående html og andre aspekter ved webutvikling, vil jeg anbefale Norsk Webforum, der jeg er moderator.
Denne artikkelen var skrevet av Bjarne Sverkeli 28. september, 2007, i kategorien webskolen. Du kan følge med på kommenater via en RSS 2.0 feed. Du kan legge inn en kommentar, og legge inn trackback fra din egen hjemmeside.
Snakk med Sverkeli kjøres av
WordPress - 
RSS for Artikler
og RSS for kommentarer.
Legg siden til dine favoritter
Jeg føler jeg må arrestere deg litt her:
“Den gjeldende anbefalte eller doctype, eller HTML-versjon om du vil, heter XHTML 1.0,…”
HTML4.01 er gjeldende HTML standard. XHTML 1.0 er gjeldende XHTML-standard. XHTML1.0 er ikke å foretrekke foran HTML4.01, de likestilles i form av gyldighet i W3C.
“Hvis man har tekst som bÃ¥de er fet og i kursiv, skal koden være sÃ¥nn: …”
Hvis man skal ha tekst som er fet og kursiv skal man bruke CSS til dette. Et span element kombinert med egenskapene font-weight og font-style ordner dette. Elementene strong og em har en semantisk betydning og den visuelle presentasjonen av de som fet og kursiv er kun en tolkning av noen nettlesere. Dette er innhold som det skal legges trykk på hvor strong vektlegges større enn em.
“UtgÃ¥tte tagger er applet, basefont, blackface, blockquote, cen…”
Blockquote er på ingen måte utgått!
“PÃ¥ samme mÃ¥te skal menyen pÃ¥ en webside komme først i dokumentet.”
Dette er jeg ikke enig i, men det har mer med tolkning enn henvisning til absolutte standarder.
Tja, XHTML er jo HTML, bare XML-basert. Du kan jo selvsagt med retten på din side hevde at HTML 4 og XHTML er likestilte i form av gyldighet, men det er nå engang slik at XHTML 1.0 er den anbefalte standard av W3C. I hvertfall tolker jeg http://www.w3.org/MarkUp/2004/xhtml-faq slik.
XHTML er XML, og derfor langt mer fleksibel, og sikrer en fremoverkompatibilitet ved tilpasning til f.eks. nye plattformer som bruker XSLT og XForms.
Når det gjelder fet og kursiv, så er det korrekt at man kan style både strong og em til krampa tar en, men default tolkning i alle nettlesere jeg har vært borti er nettopp å presentere teksten som fet og kursiv, og her var det eksempelet som var viktig, altså lukking av tagger.
Blockquote er ikke utgått, det er korrekt, og rettet. Det er min feil. (Det er utgått for xhtml 1.1, i likhet med width og height.)
Og til din siste kommentar, så handler etter min mening semantikk mest om brukervennlighet, og ikke så mye om standarder. Man kan gjøre mange krumspring innenfor standardene som verken er spesielt brukervennlige eller semantiske, og det var semantikk som var temaet her. Ville du skrevet innholdsfortegnelsen bakerst i en bok?
“XHTML er XML, og derfor langt mer fleksibel, og sikrer en fremoverkompatibilitet ved tilpasning til f.eks. nye plattformer som bruker XSLT og XForms.”
XHTML har _ingen_ fordeler foran HTML dersom man ikke presenterer det i et XML-format. Det har du ikke beskrevet her, og en ikke modulær XHTML-spesifikasjon som 1.0 er har smÃ¥ utvidelsesmuligheter sammenlignet med arbeidsdokumentet og den modulære standarden 1.1. XHTML 1.1 er “ekte” XML med ingen overgansløsninger som transitional doctype, dokumenter som text/html osv.
“NÃ¥r det gjelder fet og kursiv, sÃ¥ er det korrekt at man kan style bÃ¥de strong og em til krampa tar en, men default tolkning i alle nettlesere jeg har vært borti er nettopp Ã¥ presentere teksten som fet og kursiv, og her var det eksempelet som var viktig, altsÃ¥ lukking av tagger.”
Fet og kursiv er oppfatning av presentasjonen av elementene visuelt. Ikke alle nettlesere er visuelle, ikke alle visuelle nettlesere presenterer elementer på samme måte. Semantisk betydning av strong og em er ikke fet og kursiv. Fet og kursiv er en presentasjon.
“Ville du skrevet innholdsfortegnelsen bakerst i en bok?”
NÃ¥ er ikke en nettside en bok, men et interaktivt dokument. En meny pÃ¥ slutten med en “hopp-til-meny”-lenke i begynnelsen er etter min mening mer riktig enn en meny før innholdet. Dersom man prøver Ã¥ surfe med en audio- eller tekst basert nettleser vil man fort merke dette.
Takk for innsiktsfulle kommentarer. Jeg tror jeg velger med å konkludere med at vi er uenige, og det er helt greit. Jeg vil fortsette med å anbefale xhtml 1.0 strict, ettersom jeg ikke ser noen fordeler med å bruke html 4, men flere med xhtml.
Og ja, det er riktig det du sier om strong og em, men jeg ser heller ikke noe motseting mellom det og mitt valg av disse to taggene som eksempel på korrekt rekkefølge av tagger, og så lenge resultatet som vises på skjermen er det samme. Teksen blir uthevet (strong) og fremhevet (emphasized) og det er jo det vi er ute etter.
Når det gjelder å legge menyen til sist, så er jo dette en evig diskusjon. Når jeg kommer til et nettsted er det slett ikke alltid jeg har lyst å lese en lang røys med saker. Veldig ofte er jeg ute etter f.eks. kontaktinfo eller en søkeside, og da er det fint at denne ligger tilgjengelig på toppen av siden. Jeg synder selv på et par tilgjengelighetspunkter, som f.eks. manglende accesskeys, så jeg skal på ingen måte hevde at jeg er perfekt, men jeg jobber stadig med å bli bedre. Jeg tror likevel det skal mye til at jeg kommer til å droppe menyen først. Det er tross alt der jeg har de viktigste sidene for forretningen min, og jeg vil ikke risikere at noen går glipp av mine sider der jeg tilbyr mine tjenester og min kontaktinfo.
Jeg skal gi deg litt å tenke på. Jeg har lest bloggen din lenge, og først i dag så jeg at du har meny. Ettersom jeg bare leser toppen, har jeg aldri lagt merke til menyen på bunnen, og har bare tenkt at du kun hadde den ene siden og greide deg uten. Så det er godt mulig at blinde setter pris på å høre tale- eller brailleoversetteren lese opp menyen din, men du gjør altså viktig info temmelig vanskelig tilgjengelig for 99% av leserne dine.
Valget mellom XHTML1.0 og HTML4.01 er en evigvarende diskusjon, og vil ikke dø før en av standardene blir erstattet/degradert eller tilsvarende. Det var heller ikke meningen min Ã¥ ta opp den diskusjonen. Jeg var mer interessert i at formuleringen din om at XHTML 1.0 var “den gjeldende anbefalte…” indikerte at dette var eneste option. Her mener jeg HTML4.01 helt klart er et alternativ.
Jeg mener fortsatt at ditt eksempel med kombinasjonen strong og em er dÃ¥rlig. Ikke bare er det feil Ã¥ beskrive dette som en metode for fet og kursiv tekst, men selve markupen er semantisk ukorrekt. Dette er to elementer med samme semantiske betydning, dog gradert i forhold til vektlegging. Dersom man legger et innhold innenfor de to elementene har man smør pÃ¥ flesk, og betydningen av elementene “overstyrer” hverandre. Et bedre eksempel for Ã¥ demonstrere korrekt sekvens i lukking av elementer ville vært for eksempel et p-element inne i en blockquote. (blockquote skal som kjent alltid innehold blokknivÃ¥elementer)
Angående min nettside så har jeg bevisst plassert menyen langt fra synsvidde. Du kan lese mer om det her: http://bza.no/riktig-plassering-av-navigasjon-gir-riktig-fokuspunkt/
I tillegg har jeg en “skjult” lenke til menyen fra toppen (slÃ¥ av css eller surf med hÃ¥ndhold/tekstbasert nettleser) sÃ¥ dukker den opp. I tillegg er “menyelementene” mine merket med accesskeys.
Moro Ã¥ “krangle” nÃ¥r man møter litt motstand hos en med samme interesseomrÃ¥de!