Norsk oversettelse av Thomas Hammer.

Innhold

  1. Introduksjon
  2. Historikk
  3. Nettstandarder
  4. Struktur og presentasjon
  5. (X)HTML
  6. CSS
  7. Tilgjengelighet
  8. URLer
  9. Referanser
  10. Ordliste

1. Introduksjon

Dette dokumentet forklarer hvorfor og hvordan man gjennom å benytte nettstandarder kan bygge nettsteder som både sparer tid og penger for utviklerne og eierne av nettstedet samtidig som det gir den besøkende en bedre opplevelse. Dessuten diskuteres en del andre metoder, retningslinjer og gode eksempler på hvordan man kan produsere nettsteder med høy kvalitet og som samtidig er tilgjengelige for så mange som mulig.

2. Historikk

Da internett slo i gjennom for alvor, sent på nittitallet, hadde ikke nettleserprodusentene implementert CSS, Cascading Style Sheets, godt nok til at det var praktisk å benytte CSS til å kontrollere hvordan et HTML-dokument ble presentert. Det er til en viss grad forståelig, med tanke på at spesifikasjonen for CSS Level 1 ble publisert i 1996 og CSS Level 2 ble publisert i 1998.

Mangelen på støtte for CSS i nettleserne, kombinert med kravene fra designere med bakgrunn fra trykksakproduksjon, førte til at man mishandlet HTML på alle mulige og umulige måter for å få kontroll på utseendet. Det var et stort gjennombrudd for designere da man oppdaget at man kunne bruke attributtet border="0" for å gjøre kantlinjene til en tabell usynlige, og dermed bruke table-elementet til å lage et rutenett som man kan basere layouten på. En annen ting man også gjorde var å bruke gjennomsiktige, usynlige GIF-bilder for å kontrollere layouten.

Men det er ikke meningen at HTML skal brukes til å kontrollere utseendet til dokumentet, og derfor ble koden full av hacks, feilaktigheter og elementer (tagger) og attributter som bare fungerer i bestemte nettlesere. Validering var noe som nesten ingen kjente til eller benyttet seg av. Det engelske uttrykket ”tag soup”, taggesuppe, er meget treffende for denne typen kode, en eneste stor røre.

Etter hvert som nettleserne kom i nye varianter har støtten for CSS utviklet seg, om enn noe langsommere enn man skulle ønske. Men på tross av den langsomme utviklingen er vi nå kommet til et punkt der så mange bruker nettlesere med tilstrekkelig støtte for CSS at det ikke lenger finnes noen grunn til ikke å bruke HTML slik det er ment å brukes: Å beskrive hvordan innholdet i et dokument er strukturert, ikke hvordan det skal presenteres. Presentasjonen styres i stedet ved hjelp av CSS, som er laget akkurat for det formålet.

3. Nettstandarder

Hva er nettstandarder?

World Wide Web Consortium (W3C) og andre standardiseringsorganer har etablert nettstandardene, teknologier som brukes til å lage og tolke nettbasert innhold. Disse teknologiene skal garantere holdbarheten for et dokument som publiseres på nettet, og samtidig gjøre disse dokumentene tilgjengelige for så mange nettbrukere som mulig. Nettsteder som er utviklet i samsvar med disse standardene komme til å fungere korrekt også i framtidige nettlesere.

Strukturelle språk

Presentasjonsspråk

Objektmodeller

Skriptspråk

Her diskuteres hovedsaklig XHTML 1.0 Strict for struktur, CSS Level 1 og Level 2 for presentasjon og ECMAScript 262 for skripting (men det ikke er så mange eksempler på det siste her).

Når man sier at et dokument følger nettstandarder pleier man å mene at dokumentet, i tillegg til å bruke de nevnte teknologiene:

Merk at ”fungere i alle nettlesere” ikke er det samme som ”se eksakt lik ut i alle nettlesere”. Det er nesten umulig å oppnå. Ikke engang ved å bruke bare bilder kan man få et nettsted til å se eksakt lik ut overalt. Man gjør det mye lettere for seg selv om man aksepterer at dokumenter som publiseres på nettet kommer til å presenteres ulikt fordi nettlesere er forskjellige, og det er operativsystem, skjermer, forhåndsinnstilt tekststørrelse og andre innstillinger brukeren har lagret på sin maskin også. Akkurat som at de som lager trykksaker, kinofilmer eller jobber med TV har tekniske forutsetninger å rette seg etter, må den som lager nettsider forstå hvilke forutsetninger som gjelder for sitt eget medium.

Hvorfor bruke nettstandarder?

Hos visse utviklere og designere som lager nettbaserte løsninger er det motstand mot å bruke nettstandarder. Noen vanlige argument er at det er for vanskelig, det fungerer samme hvordan vi gjør det eller verktøyene som jeg bruker lager ugyldig kode.

Folk har lett for å reagere følelsesmessig og være motstander av å lære seg noe nytt, og dermed også legge bak seg utviklingsmetoder som man allerede kjenner og er trygg på. Om man derimot ser logisk på det hele finnes det mange fordeler med å lære seg å bruke nettstandarder. Noen eksempler:

Oppsummeringsvis kan man si at nettstandarder kan spare tid og penger for den som bygger et nettsted og gi nettstedets besøkende en bedre opplevelse. Dessuten er det dit utviklingen er på vei. Om man ikke ennå har begynt å bruke nettstandarder er det på tide å begynne. Ellers er risken stor for at man havner i bakleksen.

Les mer:

Validering

Å validere et dokument innebærer at man kontrollerer om det følger de reglene som finnes for språket som brukes i dokumentet. Man kan sammenligne det med å kontrollere om en tekst er rettskrevet og grammatisk korrekt.

Validering er en viktig del av utvikling for nettet. Mange feil er vanskelige å få øye på, men kommer tydelig fram med validering. Det kan være noe så enkelt som et skeivt tastetrykk eller noe så alvorlig som at man bruker et element eller et attributt på feil måte.

Dessverre er det mange som ikke validerer dokumentene sine. Enten fordi de ikke vet at man bør gjøre det eller fordi de glemmer det, andre unnlater bevisst å gjøre det. At det har blitt slik kan man i stor grad laste nettleserne for. De fleste nettlesere forsøker å tolke ugyldig XHTML så godt de kan, og gjetter på hva den som har laget dokumentet mener i stedet for å vise feilmeldinger. Det har igjen ført til denne upresise oppmerkingen av dokumenter har blitt mer vanlig. Problemet er at slik oppmerking gir uforutsigbare resultater, helt avhengig av feilhåndteringen til de ulike nettleserne.

Det finnes ingen ulemper med å ikke validere XHTML og CSS. Tvert imot. Det finnes bare fordeler.

Mark Pilgrim har skrevet en svært bra beskrivelse av fordelene i artikkelen Why we won’t help you. Der forklarer han hvorfor det kan være vanskeligere å få hjelp fra diskusjonsfora og epostlister hvis man ikke først har validert dokumentet man trenger hjelp med.

Flere HTML-editorer, som for eksempel BBEdit og Homesite, har validering innebygd. For den som bruker verktøy som ikke har slikt innebygd finnes W3Cs valideringstjenester:

Det kan være vanskelig å forstå feilmeldingene som validatorene kommer med. En liten enkeltfeil tidlig i dokumentet kan også føre til at man får mengder av følgefeil. Når man fikser den første feilen og validerer igjen kan man ofte minske antallet filmeldinger drastisk. Noen av de vanligste feilmeldingene er forklart hos Black Widow Web Design: Common XHTML Validation Errors.

Det er alltid bra å se til at man har validert koden sin, men det finnes tilfeller der det kan være vanskelig å unngå visse valideringsfeil. Det vanligste eksempelet er om man vil bruke Flash eller annet innhold som krever et lite tilleggsprogram. Les mer om problematikken med Flash i Flash Satay: Embedding Flash While Supporting Standards og Embedding flash without <embed>.

4. Struktur og presentasjon

Noe som ofte nevnes når man nevner diskuterer nettstandarder er hvor viktig det er å separere innhold og struktur fra presentasjonen. Det kan være vanskelig å forstå forskjellen, spesielt om man ikke er vant til å tenke på dokumentets logiske struktur. Men dette er noe som viktig å ha klart for seg, for det er mye enklere å kontrollere presentasjonen av et dokument med CSS når struktur og presentasjon er separerte.

Struktur er de delene av et dokument som er obligatoriske og den logiske oppmerkingen av dokumentets innhold.

Presentasjon er den stilen man gir innholdet. Oftest mener man utseende eller form, men det kan også handle om hvordan et dokument høres ut – det er nemlig ikke alle som bruker grafiske nettlesere.

Struktur og presentasjon skal separeres så langt det er mulig. Det innebærer at strukturen finnes i et HTML-dokument og utseendet kontrolleres av CSS.

Separasjon av struktur og presentasjon er uvanlig å se. På de fleste nettsteder mangler HTML-koden både struktur og logikk.

Tabeller til layout

For å separere struktur fra presentasjon må man bruke CSS i stedet for tabeller for å kontrollere hvordan dokumentet presenteres. For de som er vant til å bruke tabeller for layout kan det kjennes uvant og fremmed, men det er ikke så vanskelig som det kan virke i begynnelsen. Det finnes mye hjelp å få på nettet, og fordelene er så mange at det absolutt er verdt å ta seg tid til å sette seg inn i tankesettet.

Les mer:

Logisk HTML

Et annet, viktig punkt når man separerer struktur fra presentasjon er å bruke logisk oppmerking for å strukturere innholdet på en bra måte. I mange tilfeller finnes det et XHTML-element som har akkurat den strukturelle betydningen som passer for det innholdet som skal oppmerkes. Da skal dette brukes, det finnes ingen grunn til å bruke noe annet. CSS skal altså ikke brukes til å få HTML-elementer til å se ut som andre HTML-elementer, for eksempel ved å bruke et <span>-element i stedet for et <h1>-element for å lage en overskrift.

Når man skriver logisk HTML gir man dokumentets ulike deler en betydning for alle typer nettlesere, uansett om det er den aller nyeste grafiske nettleseren på en moderne PC, en gammel nettleser som ikke håndterer CSS eller en tekstbasert nettleser på en Unix-terminal.

Overskrifter

Man merker opp overskrifter med <h1>, <h2>, <h3>, <h4>, <h5> eller <h6> avhengig av nivå, der <h1> angir det øverste nivået.

Eksempel:
<h1>Dokumentets overskrift</h1>
<h2>Underoverskrift</h2>

Dokumentoverskrift

Underoverskrift

Avsnitt

Avsnitt skal merkes opp <p>-elementet. Ikke bruk <br />-elementet for å skape luft mellom avsnittene. Marger mellom avsnitt håndteres ved hjelp av CSS, og forutsetter at avsnittene merkes opp på riktig måte.

Eksempel:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

Lister

Når man har en liste av saker skal den markeres som en liste. Det finnes tre ulike typer lister i XHTML: Unummererte lister, nummererte lister og definisjonslister.

En unummerert liste, eller punktliste, begynnes med <ul> og avsluttes med </ul>. Hvert punkt på listen ligger inni et <li>-element.

En nummerert liste begynnes med <ol> og avsluttes med </ol>.

Definisjonslister fungerer litt annerledes, og brukes for eksempel til å markere en liste over ulike begrep med tilhørende forklaringer. Definisjonslister begynnes med <dl> og avsluttes med </dl>. Hvert begrep som beskrives markeres med et <dt>-element, og forklaringen ligger i etter eller flere <dd>-element.

Eksempel:
<ul>
    <li>Punkt 1</li>
    <li>Punkt 2</li>
    <li>Punkt 3</li>

</ul>
<ol>

    <li>Punkt 1</li>
    <li>Punkt 2</li>
    <li>Punkt 3</li>
</ol>
  1. Punkt 1
  2. Punkt 2
  3. Punkt 3
<dl>
    <dt>nettsted</dt>

    <dd>nettside eller gruppe sammenlenkede nettsider som
    inneholder informasjon om en virksomhet eller ett emne og
    som har samme utgiver</dd>
    <dt>nettside</dt>
    <dd>mengde informasjon som man når via nettet uten å
    trenger å gå videre via en lenke; tilsvarer ofte så mye man
    kan se på skjermen samtidig eller gjennom å rulle bildet</dd>
</dl>
nettsted
nettside eller gruppe sammenlenkede nettsider som inneholder informasjon om en virksomhet eller ett emne og som har samme utgiver
nettside
mengde informasjon som man når via nettet uten å trenger å gå videre via en lenke; tilsvarer ofte så mye man kan se på skjermen samtidig eller gjennom å rulle bildet

CSS gjør det mulig å bruke lister til og med der man ikke vil at innholdet skal presenteres som en tradisjonell liste. Et godt eksempel er menyer, som jo faktisk er lister med lenker. Fordelen med å bruke lister i slike tilfeller er at menyen blir lettere å bruke også for de som bruker nettlesere som mangler støtte for CSS.

Sitater

For korte sitater inni avsnitter skal <q>-elementet benyttes. Det er meningen at nettleseren automatisk skal skrive ut riktige sitattegn rundt et slikt sitat. Dessverre mangler Internet Explorer støtte for dette, og i visse tilfeller kan <q>-elementet til og med lage tilgjengelighetsproblemer. Derfor anbefaler noen at man inntil videre unngår å bruke <q>, og i stedet legger inn sitattegn manuelt. Når man legger sitat inn i et <span>-element med en passende klasse kan man styre hvordan de presenteres, men den semantiske verdien går tapt. Les Mark Pilgrims The Q tag for en detaljert beskrivelse av problemet med <q>-elementet.

Lengre sitater som går over flere avsnitt legges i et <blockquote>-element. Da kan man bruke CSS til å gi sitatet innrykket marg eller andre typer stiler. Legg merke til at tekst ikke kan ligge direkte i et <blockquote>-element – den må ligge i et annet element, vanligvis et <p>-element. Man kan kan bruke cite-attributtet for å angi en URL til kilden man siterer.

cite-attributtet kan brukes med både <q>- og <blockquote>-elementene for å angi en URL til sitatets kilde. Legg merke til at dersom man bruker <span> i stedet for <q> til sitater inni et avsnitt kan cite-attributtet ikke brukes.

Eksempel:
<p>W3C sier at <q cite="http://www.w3.org/TR/REC-html40/
struct/text.html#h-9.2.1">The presentation of phrase elements
depends on the user agent.</q>.</p>

W3C sier at The presentation of phrase elements depends on the user agent..

<p>W3C sier at <span class="quote">&rdquo;The presentation of
phrase elements depends on the user agent.&rdquo;</span>.</p>

W3C sier at ”The presentation of phrase elements depends on the user agent.”.

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">

    <p>&rdquo;The following sections discuss issues surrounding
    the structuring of text. Elements that present text (alignment
    elements, font elements, style sheets, etc.) are discussed
    elsewhere in the specification. For information about characters,
    please consult the section on the document character set.&rdquo;</p>
</blockquote>

”The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.”

Vektlegging

For å vektlegge noe brukes <em>, og for sterk vektlegging brukes <strong>. De fleste nettlesere viser vektlagt tekst i kursiv stil, og sterkt vektlagt tekst i fet stil. Det finnes ingen krav til nettleserne om at det skal være sånn, så hvis man vil være helt sikker på hvordan vektlagt tekst skal vises bør man spesifisere utseendet i CSS.

Eksempel:
<p>En <em>vektlagt</em> tekst vises vanligvis i kursiv stil,
mens en <strong>sterkt vektlagt</strong> tekst oftest vises
i fet stil.</p>

En vektlagt tekst vises vanligvis i kursiv stil, mens en sterkt vektlagt tekst oftest vises i fet stil.

Tabeller

XHTML-tabeller bør ikke brukes til layout, <table> og tilhørende elementer og attributter skal brukes til å vise tabelldata. For å gjøre tabeller så tilgjengelige som mulig er det viktig å kjenne til og bruke de ulike delene som kan inngå i en tabell. Som eksempel kan nevnes tabelloverskrifter (<th>), oppsummeringer (summary-attributtet) og bildetekster (<caption>-elementet).

Eksempel:
<table class="example" summary="Denne tabellen viser den årlige
folkeøkningen i Sverige i årene 1999 til 2003.">
    <caption>Årlig folkeøkning i Sverige, 1999–2003</caption>
    <thead>

        <tr>
            <td>&#160;</td>
            <th scope="col">1999</th>
            <th scope="col">2000</th>

            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
        </tr>

    </thead>
    <tbody>
        <tr>
            <th scope="row">Folkemengde</th>
            <td>8 861 426</td>

            <td>8 882 792</td>
            <td>8 909 128</td>
            <td>8 940 788</td>
            <td>8 975 670</td>

        </tr>
        <tr>
            <th scope="row">Folkeøkning</th>
            <td>7 104</td>

            <td>21 366</td>
            <td>26 368</td>
            <td>31 884</td>
            <td>34 882</td>

        </tr>
    </tbody>
</table>
Årlig folkeøkning i Sverige, 1999–2003
  1999 2000 2001 2002 2003
Folkemengde 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Folkeøkning 7 104 21 366 26 368 31 884 34 882

For en mer inngående beskrivelse av tabeller og hvordan de brukes, se Tables in HTML documents og HTML Techniques for Web Content Accessibility Guidelines 1.0.

Les mer:

5. (X)HTML

Det går like bra å bygge moderne, strukturerte nettsteder som følger nettstandarder med HTML 4.01 som med XHTML 1.0, men for å påskynde overgangen til ren, semantisk kode og være bedre forberedt for en eventuell overgang til XML og andre framtidige oppmerkingsspråk, anbefaler jeg at man bruker XHTML 1.0 Strict for nyproduserte nettsteder. Det er også dette som brukes i eksemplene i dette dokumentet.

XHTML 1.0 er en omformulering av HTML 4 i XML 1.0, og er utviklet for å erstatte HTML. XHTML 1.0 Strict, som er det jeg anbefaler å bruke, tillater ikke elementer eller attributter som styrer presentasjonen (det gjør ikke HTML 4.01 Strict heller, men jeg har valgt å fokusere på XHTML her). Dermed tvinger XHTML 1.0 Strict fram separasjonen av struktur og presentasjon.

XHTML 1.1, som er den nyeste versjonen av XHTML, er teknisk sett noe mer problematisk å bruke, ettersom spesifikasjonen sier at slike dokumenter bør ha MIME-typen application/xhtml+xml, og ikke bør sendes som text/html. Det er ikke strengt forbudt å bruke text/html, men det bør unngås. Derimot kan HTML-kompatibel XHTML 1.0 sendes med MIME-typen text/html, selv om man bør bruke application/xhtml+xml. Se W3Cs dokument XHTML Media Types for en oversikt over de MIME-typer som anbefales av W3C.

Dessverre har flere eldre nettlesere og Internet Explorer ingen anelse om hva application/xhtml+xml er, og kan reagere med å vise kildekoden, eller la være å vise dokumentet i det hele tatt.

Om man vil bruke application/xhtml+xml bør man derfor la serveren sjekke om nettleseren som spør etter et dokument kan håndtere den MIME-typen. Da kan den brukes, men ellers bør text/html brukes for andre nettlesere.

Om man bruker PHP som skriptspråk på serveren kan man bruke følgende skript for å sende ulike MIME-typer til ulike nettlesere:

<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
    header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
    header("Vary: Accept");
    echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
    }
else {
    header("Content-Type: text/html; charset=iso-8859-1");
    header("Vary: Accept");
    }
?>

Skriptet sjekker om nettleseren sender en HTTP header som inneholder ”application/xhtml+xml”, eller om det er W3Cs HTML-Validerer som spør etter dokumentet. Den sender ikke en fullstendig Accept HTTP header, men håndterer bare application/xhtml+xml. I begge tilfeller sendes dokumentet som application/xhtml+xml. En XML-deklarasjon sendes også. Til andre nettlesere, inkludert alle versjoner av Internet Explorer, sendes dokumentet som text/html. Ingen XML-deklarasjon legges til i begynnelsen av dokumentet, ettersom det får IE/Win til å bruke bug mode, og det vil vi ikke.

Etter Content-Type headeren sendes en Vary header for å informere mellomliggende cacher, for eksempel proxyservere, om at dokumentets MIME-type varierer avhengig av hva nettleseren som spør etter dokumentet kan håndtere.

For et mer avansert PHP-basert skript, gå til Serving up XHTML with the correct MIME type. Det skriptet tar også hensyn til nettleserens q-rating (hvor godt den sier at den kan håndtere en spesiell MIME-type), og konverterer XHTML till HTML 4 før dokumentet sendes som text/html til nettlesere som ikke håndterer application/xhtml+xml.

Her er et lignende skript for ASP and VBScript:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
    Response.ContentType = "application/xhtml+xml"
    Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
    Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Det er lurt å vite at når MIME-typen application/xhtml+xml brukes, vil nettlesere som Mozilla med flere unnlate å vise enkelte dokumenter som inneholder ugyldig XHTML. Det kan være bra når man utvikler eller feilsøker, men kan være problematisk på et publisert nettsted om man ikke alltid har full kontroll over at all kode er og forblir korrekt. Om så er tilfellet kan det være aktuelt å overveie om man skal bruke HTML 4.01 Strict i stedet.

Her er en liste over de viktigste tingene man må tenke på når man skal skrive XHTML i stedet for HTML:

Les mer:

Doktype

I dag har veldig få HTML-dokumenter en korrekt doktype, eller DTD (Document Type Declaration). Tidligere var doktypen der mer av dekorative formål enn fordi den var funksjonell, men for noen år siden endret det seg. Nå kan det samme dokumentet vises forskjellig i samme nettleser avhengig av om man har med en dokumenttypedeklarasjon eller ikke.

Alle HTML- og XHTML-dokumenter må ha en dokumenttypedeklarasjon for å være gyldige. Deklarasjonen angir hvilken versjon av HTML eller XHTML dokumentet benytter, og brukes både når man validerer dokumentet og når nettleseren skal bestemme om den kan bruke standardmodus eller ikke. Når en fullstendig, korrekt dokumenttypedeklarasjon er på plass i et dokument kommer mange nettlesere til å bytte til standardmodus, hvilket innebærer at de kommer til å tolke CSS mer korrekt. Dessuten kommer dokumentet til å vises kjappere ettersom nettleseren ikke trenger å forsøke å tolke og kompensere for ugyldig HTML. Det gjør også at forskjellen mellom hvordan ulike nettlesere viser dokumentet minsker.

Følgende doktype angir at dokumentet er XHTML 1.0 Strict og gjør at de nettlesere som har såkalt ”doctype switching” benytter standardmodus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Les mer:

Tegnenkoding

Man skal alltid angi hvilken tegnenkoding som benyttes i et XHTML-dokument.

Det beste er om nettserveren kan innstilles på å sende en HTTP content-type header som angir hvilken tegnenkoding som brukes. For mer detaljert informasjon om hvordan man gjør dette, se dokumentasjonen for nettserverprogramvaren din.

De som bruker Apache kan angi tegnenkodingen ved å legge til en eller flere regler i .htaccess-filen. For å angi at alle filer skal bruke for eksempel utf-8, legger man til følgende:

AddDefaultCharset utf-8

For å angi tegnenkodingen for alle filer med en viss filendelse brukes følgende:

AddCharset utf-8 .html

Hvis man kan kjøre PHP-skript på nettserveren kan følgende brukes til å angi tegnenkodingen:

<?php
    header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

For å sende dokumentene som HTML, endre application/xhtml+xml til text/html. Om man av en eller annen grunn ikke har mulighet til å konfigurere nettserveren slik at den angir tegnenkodingen som brukes, bør man bruke et <meta>-element i dokumentets <head>-seksjon for å angi tegnenkodingen. Det er for øvrig en god idé å gjøre det uansett om nettserveren er korrekt innstilt.

For eksempel angir

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />

at man benytter tegnenkodingen ISO-8859-1.

Les mer:

6. CSS

CSS var lenge et verktøy som bare ble brukt til å angi skriftsnitt og tekststørrelse, men nå kan CSS brukes til å kontrollere hele layouten til et dokument. Men for å gjøre det på en effektiv måte, kreves det en litt annen angrepsvinkel enn når man bruker tabeller til å kontrollere layouten.

Strukturert, logisk XHTML er en forutsetning for at man på en effektiv måte skal kunne kontrollere presentasjonen med CSS.

Nettleserstøtte

Som nevnt tidligere har nettlesernes støtte for CSS blitt forbedret en hel del de senere årene. Dessverre er ikke alle nettleserprodusenter like interesserte i å følge åpne standarder, så støtten varierer en del. Dessuten finne det, som alltid når det gjelder programvare, småfeil som gjør at nettleserne ikke oppfører seg slik som de burde i alle tilfeller.

De nettleserne som har best støtte for CSS er i dag (2004) Mozilla (og andre nettlesere som er basert på Gecko: Firefox (tidligere Firebird), Camino, Netscape 6+), Opera og Safari (og andre nettlesere basert på WebCore: OmniWeb 4.5 og senere). Internet Explorer 6/Win har ikke like god støtte, men den har kommet et stykke på vei. Internet Explorer 5/Mac har veldig god støtte for CSS 1, men det manger støtte for en stor del av CSS 2. IE 5.* for Windows har noenlunde god støtte, men har enkelte problemer som man bør kjenne til. Tidligere versjoner av Internet Explorer har ingen eller så dårlig støtte for CSS at den ikke er verdt å nevne. Det samme gjelder for Netscape før versjon 6.

Ettersom Internet Explorer er den nettleseren som akkurat nå har flest brukere, må man ofte lage en overordnet layout som er tilpasset det Internet Explorer forstår. Det er ikke dermed sagt at man ikke kan eller skal gi de besøkende som har en moderne nettleser en ennå bedre opplevelse.

Alle nettlesere som brukes i dag har altså ikke den støtten for CSS som kreves for at man skal kunne presentere et nettsted på et grafisk attraktiv måte. Heldigvis er det bare noen små prosent som fortsatt bruker så gamle nettlesere.

Det er viktig å poengtere at disse brukerne ikke blir utestengte. På 90-tallet var det populært å bruke nettleserkontroller for å henvise den som brukte ”feil” nettleser (vanligvis hva som helst bortsett fra Internet Explorer/Win) til en side som forklarte at man måtte ”oppgradere” sin nettleser for å slippe inn.

I dag kan man håndtere eldre nettlesere på en mye bedre måte. En stor fordel med å benytte logisk, velformet XHTML er at slike dokumenter er tilgjengelige og brukbare også uten stilark. Presentasjonen, utseendet, blir ikke det samme som i en moderne nettleser, men innholdet er der og det er tilgjengelig. I de aller fleste tilfeller, og for de aller fleste som besøker et nettsted, er innholdet viktigere enn det ytre utseendet. Derfor er det bedre å slå av CSS for nettlesere med dårlig støtte enn å stenge besøkende ute.

Det finnes ulike metoder for å gjøre dette. En av de mest vanlige er å bruke @import for å lenke inn CSS-filen. Netscape 4 og eldre forstår ikke @import, og kommer derfor ikke til å lese CSS-filen. Det finnes mange andre måter å gjemme CSS fra nettlesere. Felles for de fleste er at de utnytter feil og mangler i nettlesernes måte å tolke CSS på. Det er en liten risk med dette, for når en nettleser oppdateres kan feilen som utnyttes for å gjemme CSSen være fikset, men det er kanskje ikke CSS-problemet som var årsaken til at man gjemte CSS fra nettopp denne nettleseren. Jo mindre man bruker slike CSS-hacks, jo bedre.

Man kan naturligvis også utføre en nettleserkontroll på serversiden, og bruke den for å sende ulike CSS-filer (eller ingen CSS-filer) til ulike nettlesere. Hvis man gjør det må man se til at man holder nettleserkontrollen oppdatert, slik at man ikke ved en feiltakelse sender feil CSS-fil når nettlesere oppdateres eller nye nettlesere kommer til.

Les mer:

Ulike måter å tilordne CSS

Det finnes flere ulike måter å tilordne CSS til et element i et HTML-dokument.

Eksternt

Det er flere fordeler ved å ha alle CSS-regler i en eller flere separate filer. HTML-dokumentene blir mindre. CSS-filene lagres i nettleserens cache-minne og trenger bare å lastes ned en gang. Man trenger bare endre en fil for å endre presentasjonen for et helt nettsted. En ekstern CSS-fil kan se slik ut:

h1 {
    font-weight:bold;
}

Legg merke til at det ikke skal finnes noen <style>-elementer i en ekstern CSS-fil.

Man kan lenke en CSS-fil til et HTML-dokument med et <link>-element:

<link rel="stylesheet" type="text/css" href="styles.css" />

eller med en @import-regel i et <style>-element:

<style type="text/css">
@import url("styles.css");
</style>

Inline

Ved å bruke attributtet style kan man tilordne CSS direkte på et HTML-element:

<h1 style="font-weight:bold;">Overskrift</h1>

Man bør unngå dette ettersom det innebærer at man blander struktur og presentasjon.

Internt

CSS som ligger i et <style>-element, som i sin tur ligger i <head>-elementet:

<style type="text/css">
h1 {
    font-weight:bold;
}


</style>

Dette bør også unngås, ettersom det beste er å ha HTML og CSS i separate filer.

Les mer:

Syntaks

En CSS-regel består av en selektor og en eller flere deklarasjoner. Selektoren avgjør hvilket eller hvilke HTML-elementer som påvirkes av regelen. Hver deklarasjon i sin tur består av en egenskap og en verdi. Deklarasjonene omgis av { } (klammeparentes), og hver deklarasjon avsluttes med ; (semikolon).

En enkel CSS-regel ser slik ut:

p {
    color: #0f0;
    font-weight: bold;
}

I detta tilfellet er selektoren p, hvilket innebærer at regelen kommer til å påvirke alle <p>-elementer i dokumentet. Regelen har to deklarasjoner, som til sammen kommer til å gjøre all tekst i <p>-elementet grønn og fet.

For en mer detaljert beskrivelse av CSS-regler, se for eksempel CSS Beginner's Guide, CSS from the Ground Up eller en annen god bok om emnet.

Les mer:

Overflødige elementer og klasser

Vanlige feiltakelser når man begynner å benytte XHTML og CSS er å bruke unødvendige XHTML-elementer, overflødige klasser og ekstra <div>-elementer. Det trenger ikke nødvendigvis innebære at koden blir ugyldig, men det motarbeider en del av formålet med å separere struktur fra presentasjon: å få enklere, renere kode.

Et eksempel på bruk av overflødige XHTML-elementer:

<h3><em>Overskrift</em></h3>

Om man ønsker at overskriften skal være kursiv er det bedre å benytte CSS til det:

h3 {
    font-style:italic;
}

Overflødig bruk av klasser kan se slik ut:

<div id="main">
    <div class="maincontent">
        <p class="maincontenttext">
            Lorem ipsum dolor
        </p>

    </div>
</div>

Det holder med følgende:

<div id="main">
    <div>
        <p>

            Lorem ipsum dolor
        </p>
    </div>
</div>

For å kontrollere elementer som ligger i div#main kan man senere benytte kontekstuelle selektorer i sin CSS-kode. I dette tilfellet kan det se slik ut:

div#main p {
    /* regler */
}

Man kan i de fleste tilfeller benytte CSS for å få logisk XHTML til å presenteres akkurat som man vil uten å trenger å legge til overflødig kode. Men det finnes også tilfeller der det kan være verdt litt ekstra kode for å oppnå en spesiell visuell presentasjon.

CSS-tips

Naturligvis støter man på visse problemer og vanskeligheter når man begynner å bruke CSS for alvor. En del kan bero på misforståelser, andre på utydelige spesifikasjoner eller feil i nettlesere. CSS Crib Sheet av Dave Shea er en samling gode råd. Her er noen av de viktigste, fritt oversatt til norsk, pluss noen flere som ikke kom med.

CSS-Layouts

Det finnes mange eksempler og steg-for-steg-forklaringer som viser hvordan man kan bruke CSS til å lage ulike typer layouts. Et råd er at man begynner med en enkel layout, lærer seg hvordan den fungerer og siden gir seg i kast med mer avanserte saker.

Les mer:

7. Tilgjengelighet

Med tilgjengelighet betyr ikke bare støtte for funksjonshemmede, selv om det er der hovedtyngden ligger. Et tilgjengelig nettsted fungerer bedre for alle, uansett om man er funksjonshemmet eller ikke, og kan brukes av flere mennesker med flere typer nettlesere og apparater.

En relativt vanlig misforståelse er at et nettsted som er tilgjengelig for alle ser mindre attraktiv eller annerledes enn et nettsted som ikke er tilgjengelig. Det er helt feil. Tilgjengeligheten trenger ikke å påvirke utseendet i det hele tatt.

Et eksempel på tilgjengelighet som hjelper alle: En nettside bruker et skjema der folk kan melde sin interesse for et seminar. I skjemaet kan man velge om man vil gå på seminaret i Oslo, Bergen eller Trondheim, og hvert by har en radioknapp, som oftest vist som en sirkel med en prikk i midten når den er valgt. Om den som laget skjemaet ikke har tenkt på tilgjengeligheten, må den som bruker grafiske nettlesere bruke musen og klikke akkurat på den lille sirkelen for å velge by. Hvis utvikleren har tenkt på tilgjengeligheten, kan man også klikke på bynavnet. Hva er lettest for den som skal fylle ut skjemaet?

Når man bruker logisk, velstrukturert XHTML er en stor del av jobben gjort. For å få et første overblikk over hvor tilgjengelig et dokument er, kan man bruke en tekstbasert nettleser som Lynx. Hvis innholdet fortsatt virker fornuftig og sammenhengende har man kommet et stykke på vei. Dette er langt fra det eneste man skal gjøre for å kontrollere tilgjengeligheten, men det er en god start.

Her følger en gjennomgang av noen teknologier som stiller særskilte krav til at man som utvikler har kunnskap om tilgjengelighet.

Rammer

Mange synes rammer er et godt verktøy for å dele nettleservinduet opp i flere uavhengige deler som består av separate dokumenter. Det kan være brukbart i visse tilfeller, for eksempel i en intranettløsning eller lignende. På et offentlig nettsted finnes det derimot mange bakdeler med å bruke rammer:

Dessuten gjør man det unødvendig vanskelig for seg selv. Rammer gjør et nettsted mer teknisk komplisert.

Tabeller

Det er ganske vanlig at man tolker ”ikke bruk tabeller til layout” som ”ikke bruk tabeller i det hele tatt.”. Slik er det ikke. Hvis man skal merke data som hører hjemme i en tabell så skal man bruke en tabell. Det finnes også mange måter å gjøre tabeller mer logiske og tilgjengelige.

Les mer:

Skjema

Skjema er ofte unødvendig vanskelige å bruke, delvis på grunn av at de ikke er gjennomtenkte, delvis fordi den underliggende HTML-koden ikke utnytter de elementene som finnes nettopp for å gjøre skjema mer tilgjengelige og brukbare. Elementene <label>, <fieldset> og <legend> er der for å brukes.

Et vanlig spørsmål er hva man skal bruke for å lage layout for skjemaer. Enkelte mener tabeller kan brukes, andre mener at bare CSS skal benyttes. Man kan bruke den metoden som passer best, men om man bruker tabeller må man se til at skjemaet er begripelig og brukbart selv om man lineæiserer tabellen det ligger i, det vil si om man leser tabellen rad for rad og begynner i øverste, venstre hjørne.

Les mer:

JavaScript og cookies

Unngå å være avhengig av JavaScript. Flere enn man skulle tro har slått av JavaScript, blant annet av sikkerhetsgrunner eller for å slippe popupvinduer. Eller kanskje har de en nettleser som ikke har støtte for JavaScript. I følge TheCounter.com er andelen 6%, og i følge W3Schools.com er den 8%.

I mange tilfeller trenger man egentlig ikke å JavaScript for å oppnå det man trenger. Det finnes selvfølgelig tilfeller der man kan bruke JavaScript på en god måte. Et eksempel er formvalidering, å sjekke at nødvendige felter er fylt ut.

Legg merke til at dette ikke innebærer at man skal unngå å bruke JavaScript. Derimot innebærer det at man bør unngå å gjøre et nettsted avhengig av JavaScript for å fungere.

Det samme prinsippet gjelder for cookies. Ikke bruk cookies på en slik måte at nettstedet slutter å fungere dersom man ikke aksepterer de.

8. URLer

Dette avsnittet har ingen direkte tilknytning til nettstandarder, men er tatt med likevel. Grunner er at måten en URL er konstruert kan har stor innvirkning på blant annet hvor godt et nettsted indekseres at søkemotorer og hvor brukervennlig det oppleves av de besøkende.

Søkemotorer liker ikke URLer som trenger en spørrestreng for å vise riktig dokument. Det er ganske vanlig med slike URLer på nettsteder der man spør etter dynamisk innhold i en database. En slik URL kan se slik ut:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

Den enkleste måten å lage en bedre URL, både for søkemotorer og mennesker, er å endre den slik at det ser ut som om den peker til en katalog. En slik variant av eksempelet over kan se slik ut:

http://yourdomain.com/products/item/34627393474632/id/4344/

Så lar man nettserveren tolke den nye URLen slik at den internt behandles som den opprinnelige URLen med spørrestreng. Se lenkene under for beskrivelser av ulike måter å gjøre dette på. En ennå bedre, men litt mer komplisert, løsning er å endre URLene helt slik at de blir begripelige utad:

http://yourdomain.com/products/flowers/tulips/

Fordelene med URLer av denne typen er blant annet at det blir lettere for søkemotorer å indeksere nettstedet, enklere for mennesker å håndtere URLen og man slipper å avsløre hvilken serverteknikk som brukes. Det gjør også at det blir lettere å bytte serverteknikk dersom man skulle trenger det.

Hvis man velger å bruke URLer med spørrestrenger er det viktig å sørge for at eventuelle et-tegn, & i spørrestrengen er konvertert til tegnreferansen &amp;, Hvis man ikke gjør det kommer flere nettlesere, akkurat som de skal, til å se på et-tegnet som starten på en tegnreferanse. Hvis tegnene som følger direkte et-tegnet tilsvarer en slik kommer nettleseren til å konvertere URLen, og spørrestrengen ødelegges.

En annen sak som er verdt å nevne er at for de fleste nettsteder er det helt unødvendig å bruke en www-underdomene, og http://yourdomain.com/ bør anvendes i stedet for http://www.yourdomain.com. Mer informasjon om dette finnes hos no-www.org. Uansett om man bruker et www-underdomene eller ikke, er det en god idé å konfigurere nettserveren slik at den sender all trafikk til http://www.yourdomain.com/ og http://yourdomain.com/ til samme URI.

Les mer:

9. Referanser

Her er et utvalg bøker, nettsteder og epostlister som anbefales.

Bøker

CSS

Generelt om utvikling for nettet

HTML

Tilgjengelighet

Nettstandarder

XHTML

10. Ordliste

CSS (Cascading Style Sheets)
Stilmaler som beskriver hvordan et dokument skal presenteres.
HTML (HyperText Markup Language)
Brukes for att merke opp et dokuments struktur.
Presentasjon
Den stilen man gir et dokuments innhold. Oftest mener man utseende, men det kan også handle om hvordan et dokument høres ut – ikke alle bruker grafiske nettlesere.
Struktur
De delene av et dokument som er obligatoriske og den logiske oppmerkningen av dokumentets innhold.
Tilgjengelighet
Et tilgjengelig nettsted kan brukes av alle, uansett hvilken maskin- eller programvare man bruker og uansett hvilken måte man bruker til å navigere nettstedet.
Nettstandarder
Nettstandarder er teknologier, opprettet av W3C og andre standardorganer, for å lage og tolke nettbaser innhold. Disse teknologiene er laget for å sikre holdbarheten til dokumenter som er publiserte på nettet og samtidig gjøra disse dokumentene tilgjengelige for så mange nettbrukere som mulig.
Oppmerking
Når man merker opp et dokument gir man struktur og betydning til dokumentet og dets ulike deler. For nettsider brukes HTML og XHTML til dette.
Validering
Å validere et dokument innebærer at man kontrollerer om dokumentet følger de regler som finnes for det språket som blir brukt i dokumentet. Man kan sammenligne det med å kontrollere at en tekst er rettskrevet og grammatisk korrekt.
W3C (World Wide Web Consortium)
En organisasjon som lager spesifikasjoner, retningslinjer og verktøy for nettet.
XHTML (Extensible HyperText Markup Language)
HTML tilpasset til å følge reglene som gjelder for XML.
XML (Extensible Markup Language)
Et språk som ligner HTML, men som er laget for at man skal kunna beskrive data ved selv å definere passende elementer.

Kommentarer, spørsmål eller forslag? Kontakt meg.

© Copyright 2004 Roger Johansson. Norsk oversettelse av Thomas Hammer.