Translations of this article are available.
Norsk oversettelse av Thomas Hammer.
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.
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.
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.
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.
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.
Dokument fra W3C om hvordan man kan forbedre kvaliteten på sitt eget nettsted.
Mission statement for The Web Standards Project.
The Web Standards Project har skrevet en grundig forklaring av nettstandarder og hvorfor det er bra å bruke de.
Artikkel på Netscape DevEdge om hvordan virksomheter kan tjene på å bruke nettstandarder.
Artikkel fra The Web Standards Project rettet mot virksomheters markeds-, kommunikasjons- og IT-avdelinger.
Å 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>.
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.
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.
Et foredrag som ble holdt på Seyboldmessen 2003. Finnes også i svensk oversettelse: Varför tabeller för layout är dumt.
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.
Man merker opp overskrifter med <h1>, <h2>, <h3>, <h4>, <h5> eller <h6> avhengig av nivå, der <h1> angir det øverste nivået.
<h1>Dokumentets overskrift</h1> <h2>Underoverskrift</h2>
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.
<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.
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.
<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>
<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>
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.
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.
<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">”The presentation of phrase elements depends on the user agent.”</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>”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.”</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.”
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.
<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.
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).
<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> </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>
| 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.
En veldig bra ressurs for å forstå hvordan man kan resonere seg fram til måter å merke opp innhold på en logisk måte.
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:
Bruk små bokstaver og hermetegn rundt attributter: Alle navn på elementer og attributter må skrives med små bokstaver. Dessuten må alle attributtverdier omsluttes med hermetegn.
Feil: <A HREF="index.html" CLASS=internal>
Riktig: <a href="index.html" class="internal">
Avslutt alle elementer: I HTML er det tillatt å la være å avslutte visse elementer. De avsluttes da automatisk når neste element begynner. Slik er det ikke i XHTML. Alle elementer må lukkes, til og med de som ikke har noe innhold, for eksempel <img>.
Feil: <li>Punkt 1Riktig:
<li>Punkt 1</li>
Feil: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Riktig: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Feil: <br>
Riktig: <br />
Feil: <img src="bilde.jpg" alt="">
Riktig: <img src="bilde.jpg" alt="" />
Gi alle tomme attributter en verdi: I HTML finnes enkelte attributter som ikke trenger å gis en verdi. Det gjelder ikke i XHTML.
Feil: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Riktig: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Ikke bruk utgåtte elementer: Enkelte elementer og attributter som er tillatte i HTML 4.01 Transitional og XHTML 1.0 Transitional er utgåtte, det vil si at de ikke lenger inngår i spesifikasjonen, i XHTML 1.0 Strict (og i HTML 4.01 Strict). Eksempler på slike er <font>, <center>, alink, align, width og height (på visse elementer) samt background.
The Web Standards Project spør W3C om man skal bruke HTML eller XHTML og hvorfor.
Artikkel på A List Apart om overgangen fra HTML til XHTML.
Bra forklaring på hvordan XHTML og CSS brukes.
W3C forklarer forskjellene mellom XHTML 1.0 og HTML 4
Oppsummering av forskjellene mellom XHTML 1.0 Strict og Transitional
The Web Standards Project spør W3C om hvilken MIME-type man skal bruke for HTML og XHTML og hvorfor.
En oppsummering av hvilke MIME-typer som bør brukes for XHTML-dokumenter.
HTML Dogs guide til hvilke elementer og attributter man ikke bør bruke.
Et dokument om MIME-typer og hvordan man kan bruke ulike skriptspråk på serversiden for å finne hvilken MIME-type som skal sendes.
W3C forklarer hvordan mime-typer fungerer i XHTML-sammenheng.
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">
Artikkel på A List Apart om hvordan og hvorfor man skal bruke doktype.
Oppsummering av hvordan nettlesere som har Doctype Switching håndterer ulike doktypedeklarasjoner.
W3Cs offisielle liste over korrekte doktypedeklarasjoner.
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.
The Web Standards Project spør W3C om hvordan man skal angi hvilken tegnenkoding et dokument benytter.
Artikkel om ulike tegnenkodinger.
Forklaring av ulike måter å benytte spesialtegn i HTML-dokumenter.
En forklaring på hvordan man velger og angir tegnenkoding.
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.
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.
Eric Meyer beskriver fire måter å gjemme CSS fra visse nettlesere.
Oppsummering av en mengde ulike måter å gjemme CSS fra ulike nettlesere.
Dokument som diskuterer ulike måter å forbedre opplevelsen for den som bruker en moderne nettleser.
Det finnes flere ulike måter å tilordne CSS til et element i et HTML-dokument.
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>
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.
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.
Forklaring av CSS-import, mediatyper med mer.
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.
Dave Shea har med hjelp fra sine lesere oppsummert en liste med praktiske råd og tips for CSS.
John Gallant og Holly Bergevin forklarer hvordan man skriver kompakt CSS.
Meget god forklaring av ulike CSS-selektorer og hvordan de fungerer.
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.
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.
Begynn med å validere: Når du feilsøker, begynn med å validere både HTML og CSS. Mange problemer kan forårsakes av feil i koden.
Utvikle og teste CSS i den mest avanserte nettleseren først – så tester du i andre nettlesere: Om man bruker en eldre nettleser med en dårlig og/eller feilaktig implementasjon av CSS for å teste når man utvikler, kommer koden til å være tilpasset dette. Når man siden tester i en moderne nettleser er risikoen stor for at den kommer til å oppføre seg annerledes. Det er bedre å begynne med den beste nettleseren, og siden tilpasse CSS-reglene for andre nettlesere.
Forstå hvordan et elements bredde og høyde beregnes: For å få fram den faktiske høyden og bredden til et element må man legge sammen padding og border i tillegg til width eller height. I Internet Explorer 5.*/Win er det annerledes, der inkluderes padding og border inni den width eller height som er angitt.
Sett at man har følgende CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
Den totale bredden blir 360px.
10px + 20px + 300px + 20px + 10px = 360px
I Internet Explorer 5.* blir den totale bredden 300px, og innholdets bredde 240px.
300px - 10px - 20px - 20px - 10px = 240px
For å komme rundt dette problemet kan man enten bruke et CSS-hack for å angi ulike verdier til de nettleserne som gjør det riktig ig til de som gjør det feil, eller så kan man unngå å angi både width og padding eller border for et element.
For en grundig forklaring av denne såkalte boksmodellen, se dokumentet Box model.
Angi enheter for numeriske verdier: CSS krever at man angir enheter for verdier på høyde, bredde, tykkelse, tekststørrelse og så videre. Et unntak er om verdien er 0 (null). Da trengs ingen enhet, ettersom null er null uansett hvilken enhet det skulle være snakk om.
Forstå hvordan float fungerer: Float-begrepet kan være vanskelig å forstå, men det er viktig å lære seg hvordan det fungerer, ettersom man har stor nytte av float når man bygger CSS-baserte layouts. Noen svært gode beskrivelser av hvordan float fungerer er Containing Floats, Floatutorial og Float: The Theory.
”LoVe/HAte”: Pseudoklasser for lenker skal spesifiseres i rekkefølgen Link, Visited, Hover, Active.
”TRouBLed”: Når man bruker kortformen for å spesifisere margin, padding eller border for et element begynner man med den øvre og går med solen: Top, Right, Bottom, Left.
Navngi klasser og IDer etter funksjon, ikke etter utseende: Om man lager en klasse som heter .smallblue og siden trenger å gjøre teksten stor og rød, kommer klassenavnet til å være forvirrende. Det er bedre å bruke funksjons- eller strukturbeskrivende navn som .copyright eller .important.
Det er forskjell på store og små bokstaver: CSS skiller mellom store og små bokstaver når det gjelder verdien til HTML-attributtene class og id (se CSS2 syntax and basic data types).
Kontrollere IDene: Bare ett element per dokument kan ha en bestemt ID, mens hvor mange element du måtte ønske kan ha samme class.
Bare bruk tillatte tegn i navn: Verdiene til class og ID kan bare inneholde tegnene [A-Za-z0-9] og bindestrek (-). De kan ikke begynne med en bindestrek eller et siffer (se CSS2 syntax and basic data types).
Kommentér riktig: Kommentarer i CSS begynner med /* og slutter med */:
/* Dette er en kommentar */
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.
Et eksempel på hvordan man kan lage et enkelt layout med hode, to spalter og bunntekst.
Samlingsside med lenker til informasjon om ulike CSS-layouter.
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.
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:
robot.txt at søkemotorer skal indeksere undersider. På andre nettsteder bruker man JavaScript for å sende alle besøkende fra søkemotorer til startsiden. Begge disse metodene kan fungere, dersom formålet er at man vil ha færre besøkende.Dessuten gjør man det unødvendig vanskelig for seg selv. Rammer gjør et nettsted mer teknisk komplisert.
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.
Lenker til artikler som beskriver hvordan man bygger tilgjengelige tabeller.
Artikkel om hvordan man benytter tabeller til data.
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.
Artikkel om tilgjengelige skjema på WebAIM.
En artikkel som forklarer hvordan man lager bedre og mer tilgjengelige skjema.
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.
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 &, 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.
Forklaring på problemene med visse typer URLer og ulike måter å forbedre URLene sine.
Artikkel om hvorfor det er bra å avslutte URLer med /.
Samling av lenker til artikler og beskrivelser om hvordan og hvorfor man skal tenke på hvordan URLene ser ut.
En lengre forklaring på problemene som kan oppstå om en spørrestreng inneholder ukonverterte et-tegn, og en demonstrasjon av hva som kan hende.
Her er et utvalg bøker, nettsteder og epostlister som anbefales.
Prosjektbasert bok som forklarer hvordan man kan bruke CSS i praksis.
Oppfølgeren til Eric Meyer on CSS.
Referansebok som går igjennom CSS-rekommenderingene.
Grundig gjennomgang og forklaring av hva tilgjengelighet innebærer og hvordan man bygger tilgjengelige nettsteder.
W3Cs offisielle spesifikasjon.
W3Cs offisielle spesifikasjon.
En epostliste som diskuterer CSS og praktiske bruksområder.
En svensk epostliste der man diskuterer CSS og andre nærliggende tema.
Et nettsted som har samlet retningslinjer for hvordan man lager så gode nettsteder som mulig med HTML og CSS.
Samme HTML, ulike CSS. En mengde eksempler på hvordan CSS kan brukes for å gi ett og samme dokument en mengde ulike utseender.
Flere svært velskrevne artikler som forklarer hvordan man bruker CSS.
Artikler, demonstrasjoner, nettleserbugs med mer.
Ukentlig magasin som publiserer artikler om design, utvikling og innhold på nettet, med spesiell fokus på teknikker og fordeler ved å bruke nettstandarder.
En epostliste for den som lager nettsteder. Det meste som har med design og utvikling av nettsteder diskuteres på listen.
W3Cs offisielle spesifikasjon.
Et nettsted som har samlet retningslinjer for hvordan man lager så gode nettsteder som mulig med HTML og CSS.
Joe Clarks bok i onlineformat.
Mark Pilgrims bok om tilgjengelighet.
W3Cs offisielle retningslinjer for tilgjengelige nettsteder.
W33s samling av informasjon om verktøy for å evaluere og forbedre nettsteders tilgjengelighet.
”The Web Standards Project is a grassroots coalition fighting for standards that ensure simple, affordable access to web technologies for all.”
Et nettsted som har som mål å hjelpe utviklere å forklare for kunder at nettstandarder er et ønskelig valg. Se for eksempel dokumentet What Every Web Site Owner Should Know About Standards: A Web Standards Primer og The Way Forward with Web Standards.
Dave Sheas veiledning for den som vil begynne å bruke nettstandarder.
W3Cs offisielle spesifikasjon.
Et nettsted som har samlet retningsliner for hvordan man lager så gode nettsted som mulig med HTML og CSS.
Kommentarer, spørsmål eller forslag? Kontakt meg.
© Copyright 2004 Roger Johansson. Norsk oversettelse av Thomas Hammer.