Innehåll

  1. Introduktion
  2. Historik
  3. Webbstandarder
  4. Struktur och presentation
  5. (X)HTML
  6. CSS
  7. Tillgänglighet
  8. URL:er
  9. Referenser
  10. Ordlista

1. Introduktion

OBS! Innehållet i denna svenska version av Webbutveckling med standarder är delvis föråldrat och behöver uppdateras för att stämma överens med innehållet i den engelska versionen. Jag vet inte när jag kommer att få tid att göra det, så tills vidare är det bättre om du läser den engelska versionen, Developing With Web Standards.

Detta dokument förklarar varför och hur man genom att använda webbstandarder kan bygga webbplatser på ett sätt som sparar tid och pengar för utvecklare och webbplatsägare, samtidigt som det ger webbplatsbesökaren en bättre upplevelse. Dessutom diskuteras en del andra metoder, riktlinjer och allmänna goda exempel som syftar till att producera högkvalitativa webbplatser som är tillgängliga för så många som möjligt.

2. Historik

När Internet och webben slog igenom på allvar under senare delen av nittiotalet hade inte webbläsartillverkarna implementerat CSS, Cascading Style Sheets, tillräckligt bra för att det skulle vara praktiskt användbart för att styra hur ett HTML-dokument presenterades. Det är till viss del förståeligt med tanke på att specifikationen för CSS Level 1 publicerades 1996 och CSS Level 2 publicerades 1998.

Bristen på stöd för CSS i webbläsarna kombinerat med krav från formgivare fostrade inom trycksaksproduktion ledde till att man misshandlade HTML på alla möjliga och omöjliga sätt för att kontrollera utseendet. Ett stort genombrott kom till exempel när formgivare upptäckte att man kan använda attributet border="0" för att göra en tabells kantlinjer osynliga, och därmed skapa ett rutnät att styra sin layout med. Ett annat exempel är användandet av genomskinliga, och därmed osynliga, GIF-bilder för att styra en layout.

Eftersom HTML inte är tänkt att användas för att styra ett dokuments utseende blev koden full av hack, felaktigheter och webbläsarspecifika element (taggar) och attribut. Validering var något som nästan ingen kände till eller använde sig av. Det engelska uttrycket ”tag soup”, taggsoppa, är mycket träffande när det gäller denna röra av kod.

Med varje ny version av de olika webbläsarna har deras stöd för CSS utvecklats, om än långsammare än man skulle önska. Trots den långsamma utvecklingen är vi nu i ett läge där webbläsare med tillräckligt stöd för CSS används av så många att det inte längre finns någon anledning att inte använda HTML så som det var tänkt att användas: att beskriva hur ett dokuments innehåll är strukturerat, inte hur det ska presenteras. Presentationen styrs i stället med hjälp av CSS, som är skapat just för det ändamålet.

3. Webbstandarder

Vad är webbstandarder?

Webbstandarder är teknologier, etablerade av World Wide Web Consortium (W3C) och andra standardiseringsorgan, för att skapa och tolka webbaserat innehåll. Dessa teknologier är framtagna för att säkerställa hållbarheten för dokument publicerade på webben och samtidigt göra dessa dokument tillgängliga för så många webbanvändare som möjligt. Webbplatser som utvecklas för att följa webbstandarder kommer att fortsätta fungera korrekt även i nya webbläsare.

Strukturella språk

Presentationsspråk

Objektmodeller

Skriptspråk

Här diskuteras i första hand XHTML 1.0 Strict för struktur, CSS Level 1 och Level 2 för presentation och ECMAScript 262 för skriptning (även om det inte är så gott om skriptningsexempel).

När man säger att ett dokument följer webbstandarder brukar man mena att dokumentet, förutom att använda dessa teknologier:

Notera att ”fungera i alla webbläsare” inte är detsamma som ”se exakt likadan ut i alla webbläsare”. Det är näst intill omöjligt. Inte ens genom att bara använda bilder kan man få en webbplats att se exakt likadan ut överallt. Man gör det mycket lättare för sig om man accepterar att dokument som publiceras på webben kommer att presenteras olika beroende på skillnader i webbläsare, operativsystem, bildskärmar, förvald textstorlek, användarinställningar med mera. Precis som den som publicerar något i tryckt form, den som skapar film eller den som jobbar med tv har tekniska förutsättningar att rätta sig efter, måste den som skapar webbplatser förstå vilka förutsättningar som gäller för sitt medium.

Varför använda webbstandarder?

Hos vissa webbutvecklare och webbdesigners finns ett motstånd mot att använda webbstandarder. Några vanliga argument är Det är för svårt, Det fungerar ju ändå och Min utvecklingsmiljö skapar ogiltig kod.

Det är lätt att man reagerar känslomässigt och bygger upp ett motstånd mot att lära sig något nytt och överge utvecklingsmetoder man känner sig trygg med. Om man däremot ser logiskt på det hela finns många fördelar med att lära sig och använda webbstandarder. Några exempel:

Sammanfattningsvis kan man säga att webbstandarder kan spara tid och pengar för den som bygger en webbplats och ge webbplatsens besökare en bättre upplevelse. Dessutom är det dit utvecklingen är på väg. Om man inte redan har börjat använda webbstandarder är det dags att börja, annars är risken stor att man hamnar på efterkälken.

Läs mer:

Validering

Att validera ett dokument innebär att man kontrollerar att det följer de regler som finns för det språk som används i dokumentet. Man kan jämföra det med att kontrollera att en text är rättstavad och grammatiskt korrekt.

Validering är en viktig del av webbutveckling. Många fel som är svåra att se manuellt hittas vid validering. Det kan vara så enkelt som en felaktig tangenttryckning eller så allvarligt som att man använder ett element eller ett attribut på fel sätt.

Tyvärr är det många som inte validerar sina dokument på grund av att de inte vet att man bör göra det, glömmer att göra det, eller till och med aktivt undviker att göra det. Att det har blivit så kan man till stor del skylla på webbläsarna. De flesta webbläsare försöker tolka felaktig XHTML så gott de kan, och gissa vad den som har skapat dokumentet menar, i stället för att visa ett felmeddelande. Det har i sin tur lett till den slarviga uppmärkningen som är så vanlig. Problemet är att sådan uppmärkning ger oförutsägbara resultat och är beroende av webbläsarnas felhantering.

Det finns ingen anledning att inte validera sin XHTML och CSS. Tvärtom. Det finns bara fördelar.

Mark Pilgrim har skrivit en mycket bra beskrivning av fördelarna i Why we won’t help you. Den artikeln förklarar också varför det kan vara svårare att få hjälp från diskussionsforum och sändlistor om man inte har validerat sina dokument innan man ber om hjälp.

Flera HTML-redigerare, som till exempel BBEdit och Homesite, har inbyggd validering. För den som använder ett verktyg som inte har det finns W3C:s valideringstjänster:

Det kan vara lite svårt att förstå de felmeddelanden som genereras av validatorerna. Ett fel tidigt i dokumentet kan också leda till leda till att man får mängder av felmeddelanden. Genom att åtgärda det första felet och validera igen kan man ofta minska antalet felmeddelanden rejält.

Det är alltid bra att se till att man har validerat sin kod, men det finns tillfällen när det kan vara svårt att undvika vissa valideringsfel. Det vanligaste exemplet är om man vill använda Flash, eller annat innehåll som kräver ett insticksprogram, i ett dokument. Läs mer om problematiken med just Flash i Flash Satay: Embedding Flash While Supporting Standards och Embedding flash without <embed>.

4. Struktur och presentation

Något som ofta nämns när man diskuterar webbstandarder är hur viktigt det är att separera innehåll och struktur från presentation. Det kan vara svårt att förstå skillnaden, särskilt om man är van att inte tänka på ett dokuments logiska struktur, men det är viktigt att göra det eftersom det underlättar enormt om struktur och presentation är separerade när man ska styra presentationen av ett dokument med CSS.

Struktur är de delar av ett dokument som är obligatoriska och den logiska uppmärkningen av dokumentets innehåll.

Presentation är den stil som man ger innehållet. Oftast menar man utseende, eller form, men det kan också handla om hur ett dokument låter – alla använder inte grafiska webbläsare.

Separera struktur från presentation så långt det är möjligt. Det innebär att strukturen finns i ett HTML-dokument och utseendet kontrolleras med hjälp av CSS.

Separation av struktur från presentation är ovanligt att se. På de flesta webbplatser saknar HTML-koden både struktur och logik.

Tabeller för layout

För att separera struktur från presentation behöver man använda CSS i stället för tabeller för att styra ett dokuments presentation. För den som är van att använda tabeller för layout kan det kännas ovant och främmande, men det är inte så svårt som det kan verka först. Det finns gott om hjälp att få på webben, och fördelarna är så många att det absolut är värt den tid det tar att lära sig det lite annorlunda tankesätt som krävs.

Läs mer:

Logisk HTML

En annan viktig del i att separera struktur från presentation är att använda logisk uppmärkning för att strukturera innehållet på ett bra sätt. I de fall där det finns ett XHTML-element som har en strukturell betydelse som passar för den del av innehållet som ska märkas upp finns det ingen anledning att använda något annat. Använd alltså inte CSS för att få HTML-element att se ut som andra HTML-element, till exempel genom att använda ett <span>-element i stället för ett <h1>-element för att skapa en rubrik.

Genom att skriva logisk HTML ger man dokumentets olika delar betydelse för alla typer av webbläsare, oavsett om det är den allra nyaste grafiska webbläsaren på en modern PC, en gammal webbläsare som inte hanterar CSS, eller en textbaserad webbläsare i en Unixterminal.

Rubriker

Man märker upp rubriker med <h1>, <h2>, <h3>, <h4>, <h5> eller <h6> beroende på nivå, där <h1> anger den översta nivån.

Exempel:
<h1>Dokumentrubrik</h1>
<h2>Underrubrik</h2>

Stycken

Stycken ska märkas upp med <p>-elementet. Använd inte <br />-elementet för att skapa luft mellan stycken. Marginaler mellan stycken hanteras med hjälp av CSS, och förutsätter att stycken märks upp på rätt sätt.

Exempel:
<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.

Listor

När man har en lista av saker ska den märkas upp som en lista. Det finns tre olika sorters listor i XHTML: onumrerade listor, numrerade listor och definitionslistor.

En onumrerad lista, eller punktlista, påbörjas med <ul> och avslutas med </ul>. Varje punkt i listan ligger i ett <li>-element.

En numrerad lista påbörjas med <ol> och avslutas med </ol>.

Definitionslistor fungerar lite annorlunda, och används till exempel för att märka upp en lista av olika begrepp med tillhörande förklaringar. Definitionslistor påbörjas med <dl> och avslutas med </dl>. Varje begrepp som beskrivs märks upp med ett <dt>-element, och förklaringen ligger i ett eller flera <dd>-element.

Exempel:
<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>webbplats</dt>
    <dd>webbsida eller grupp sammanlänkade webbsidor som
    innehåller information om en verksamhet eller ett ämne och
    som har samma utgivare</dd>
    <dt>webbsida</dt>
    <dd>mängd information som man når via webben utan att
    behöva gå vidare via en länk; motsvarar ofta så mycket man
    kan se på skärmen samtidigt eller genom att rulla bilden</dd>
</dl>
webbplats
webbsida eller grupp sammanlänkade webbsidor som innehåller information om en verksamhet eller ett ämne och som har samma utgivare
webbsida
mängd information som man når via webben utan att behöva gå vidare via en länk; motsvarar ofta så mycket man kan se på skärmen samtidigt eller genom att rulla bilden

CSS gör det möjligt att använda listor även där man inte vill att innehållet ska presenteras som en traditionell lista. Ett bra exempel är menyer, som ju faktiskt är listor med länkar. Fördelen med att använda listor i det fallet är att menyn blir lättare att använda för den som till exempel använder en webbläsare som saknar stöd för CSS.

Citat

För korta citat inom ett stycke ska <q>-elementet användas. Det är meningen att webbläsaren automatiskt ska skriva ut rätt citationstecken runt ett sådant citat. Tyvärr saknar Internet Explorer stöd för detta, och i vissa fall kan <q>-elementet till och med ställa till med tillgänglighetsproblem. Därför rekommendar en del att man tills vidare undviker att använda <q>, och i stället lägger in citationstecknen manuellt. Genom att lägga citat i ett <span>-element med en lämplig klass kan man styra hur de presenteras, men det semantiska värdet går förlorat. Läs Mark Pilgrims The Q tag för en detaljerad beskrivning av problemen med <q>-elementet.

Längre citat som bildar ett eller flera stycken läggs i ett <blockquote>-element. CSS används för att ge citatet indragen marginal och annan stil. Observera att text inte får ligga direkt i ett <blockquote>-element – den måste ligga i ett annat element, vanligen ett <p>-element. Man kan använda attributet cite för att ange en URL till den källa man citerar.

cite-attributet kan användas med både <q>- och <blockquote>-elementen för att ange en URL till citatets källa. Observera att om man använder <span> i stället för <q> för citat inom ett stycke kan cite-attributet inte användas.

Exempel:
<p>W3C säger att <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 säger att The presentation of phrase elements depends on the user agent..

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

W3C säger att ”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.”

Betoning

För betoning används <em>, och för stark betoning används <strong>. De flesta webbläsare visar betonad text i kursiv stil, och starkt betonad text i fet stil. Dock finns inga krav på detta, så om man vill vara säker på hur betonad text visas bör man specificera utseendet i tillhörande CSS.

Exempel:
<p>En <em>betonad</em> text visas vanligen i kursiv stil,
medan en <strong>starkt</strong> betonad text oftast visas
i fet stil.</p>

En betonad text visas vanligen i kursiv stil, medan en starkt betonad text oftast visas i fet stil.

Tabeller

XHTML-tabeller bör inte användas för layout. Däremot ska data som redovisas i tabellform märkas upp med hjälp av <table> och tillhörande element och attribut. För att göra tabeller så tillgängliga som möjligt är det viktigt att känna till och använda de olika delarna som kan ingå i en tabell. Som exempel kan nämnas tabellrubriker (<th>), sammanfattningar (summary-attributet) och bildtexter (<caption>-elementet).

Exempel:
<table class="example" summary="Denna tabell visar den årliga
folkökningen i Sverige under åren 1999 till 2003.">
    <caption>Årlig folkö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">Folkmängd</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">Folkö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 folkökning i Sverige, 1999–2003
  1999 2000 2001 2002 2003
Folkmängd 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Folkökning 7 104 21 366 26 368 31 884 34 882

För en mer ingående beskrivning av tabeller och deras användning, se Tables in HTML documents och HTML Techniques for Web Content Accessibility Guidelines 1.0.

Läs mer:

5. (X)HTML

Introduktion

Det går lika bra att bygga moderna, strukturerade webbplatser som följer webbstandarder med HTML 4.01 som med XHTML 1.0, men för att påskynda övergången till ren, semantisk kod, och att vara bättre förberedd för en eventuell övergång till XML och andra framtida uppmärkningsspråk, rekommenderar jag att man använder XHTML 1.0 Strict för nyproducerade webbplatser. Det är också vad som används i exemplen i detta dokument.

XHTML 1.0 är en omformulering av HTML 4 i XML 1.0 och är framtaget för att ersätta HTML. XHTML 1.0 Strict, som är det jag rekommenderar att man använder, tillåter inte element eller attribut som styr presentationen (det gör inte HTML 4.01 Strict heller, men jag har valt att fokusera på XHTML här). Därmed tvingar XHTML 1.0 Strict fram separation av struktur och presentation.

XHTML 1.1, som är den nyaste versionen av XHTML, är tekniskt något mer problematisk att använda, eftersom specifikationen säger att sådana dokument bör ha MIME-typen application/xhtml+xml, och bör ej skickas som text/html. Det är inte strikt förbjudet att använda text/html, men det bör undvikas. Däremot kan HTML-kompatibel XHTML 1.0 skickas med MIME-typen text/html, även om man bör använda application/xhtml+xml. Se W3C:s dokument XHTML Media Types för en översikt av de MIME-typer som rekommenderas av W3C.

Tyvärr har flera äldre webbläsare och Internet Explorer ingen aning om vad application/xhtml+xml är, och kan reagera genom att visa källkoden eller helt vägra visa dokumentet.

Om man vill använda application/xhtml+xml bör man därför låta servern känna av om webbläsaren som efterfrågar ett dokument hanterar den MIME-typen och då använda den, och använda text/html för andra webbläsare.

Om man använder PHP som skriptspråk på servern kan man använda följande skript för att skicka olika MIME-typ till olika webbläsare:

<?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 kontrollerar om webbläsaren skickar en Accept HTTP header som innehåller ”application/xhtml+xml”, eller om det är W3C:s HTML-Validerare som efterfrågar dokumentet. Den skickar inte en fullständig Accept HTTP header, men hanterar ändå application/xhtml+xml. I båda fallen skickas dokumentet som application/xhtml+xml. En XML-deklaration skickas också. Till andra webbläsare, inklusive alla versioner av Internet Explorer, skickas dokumentet som text/html. Ingen XML-deklaration läggs till i början av dokumentet, eftersom det får IE/Win att använda sitt buggläge, och det vill vi inte.

Efter Content-Type headern skickas en Vary header för att informera mellanliggande cacher, till exempel proxyservrar, att dokumentets MIME-type är olika beroende på vad webbläsaren som efterfrågar dokumentet hanterar.

För ett mer avancerat PHP-baserat skript, gå till Serving up XHTML with the correct MIME type. Det skriptet tar också hänsyn till den efterfrågande webbläsarens q-rating (hur bra den uppger sig hantera en viss MIME-typ), och konverterar XHTML till HTML 4 innan dokumentet skickas som text/html till webbläsare som inte hanterar application/xhtml+xml.

Här är ett liknande skript för 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 är bra att känna till att när MIME-typen application/xhtml+xml används kommer vissa webbläsare, som till exempel Mozilla, att vägra visa dokument som innehåller felaktig XHTML. Det kan vara bra när man utvecklar eller felsöker, men kan vara problematiskt på en publicerad webbplats om man inte alltid har full kontroll över att all kod är och förblir korrekt. Om så är fallet kan det vara aktuellt att överväga om man ska använda HTML 4.01 Strict i stället.

Här är en lista av de viktigaste sakerna att tänka på när man ska skriva XHTML i stället för HTML:

Läs mer:

Doctype

I dag har väldigt få HTML-dokument en korrekt Doctype, eller DTD (Document Type Declaration). Förr var den mer dekorativ än funktionell, men sedan några år tillbaka kan närvaron av en Doctype-deklaration göra stor skillnad på hur ett dokument visas i en webbläsare.

Alla HTML- och XHTML-dokument måste ha en Doctype-deklaration för att vara giltiga. Den anger vilken version av HTML eller XHTML man använder, och används dels när man validerar dokumentet, dels för att avgöra om en webbläsare ska använda standardläge eller inte. Om en fullständig, korrekt Doctype-deklaration finns i ett dokument kommer många webbläsare att byta till standardläge, vilket innebär att de kommer att tolka CSS mer korrekt. Dessutom kommer dokumentet att visas snabbare eftersom webbläsaren inte behöver försöka tolka och kompensera för felaktig HTML. Det gör också att skillnaden mellan hur olika webbläsare visar dokumentet minskar.

Följande Doctype anger att dokumentet är XHTML 1.0 Strict och gör att de webbläsare som har så kallad ”doctype switching” använder sitt standardläge:

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

Läs mer:

Teckenkodning

Man ska alltid ange vilken teckenkodning som används i ett XHTML-dokument.

Det bästa är om webbservern kan ställas in så att den skickar en HTTP content-type header som anger vilken teckenkodning som används. För mer detaljerad information om hur man gör detta, se dokumentationen för den webbserverprogramvara som används.

Om man använder Apache, kan man ange teckenkodningen genom att lägga till en eller flera regler i sin .htaccess-fil. För att till exempel ange att alla filer använder utf-8, lägger man till följande:

AddDefaultCharset utf-8

För att ange teckenkodningen för alla filer med en viss filändelse används följande:

AddCharset utf-8 .html

Om webbservern tillåter att PHP-skript körs kan man använda följande för att ange teckenkodningen:

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

För att skicka dokumenten som HTML, ändra application/xhtml+xml till text/html. Om man av någon anledning inte kan konfigurera webbservern så att den anger den använda teckenkodningen, bör man använda ett <meta>-element i dokumentets <head>-sektion för att ange teckenkodningen. Det är för övrigt en bra idé att göra det även om webbservern är korrekt inställd.

Till exempel anger

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

att man använder teckenkodningen ISO-8859-1.

Läs mer:

6. CSS

Efter att ha varit något som använts mest för att ange typsnitt och textstorlek kan nu CSS användas för att styra ett dokuments hela layout. För att göra det på ett effektivt sätt krävs dock att man använder ett något annorlunda angreppssätt än när man använder tabeller för att styra layouten.

Strukturerad, logisk XHTML är en förutsättning för att man på ett effektivt sätt ska kunna styra presentationen med CSS.

Webbläsarstöd

Som nämnts tidigare har webbläsarnas stöd för CSS förbättrats en hel del på senare år. Tyvärr är inte alla webbläsartillverkare lika intresserade av att följa öppna standarder, så stödet varierar en del. Dessutom finns det, som alltid när det gäller programvara, buggar som gör att webbläsare inte beter sig som de borde i alla lägen.

De webbläsare som har bäst stöd för CSS är i dagsläget (början av 2004) Mozilla (och andra webbläsare baserade på Gecko: Firefox (tidigare Firebird), Camino, Netscape 6+), Opera och Safari (och andra webbläsare baserade på WebCore: OmniWeb 4.5 och senare). Internet Explorer 6/Win har inte lika bra stöd, men det räcker en bra bit på vägen. Internet Explorer 5/Mac har mycket bra stöd för CSS 1, men det saknar stöd för en stor del av CSS 2. IE 5.* för Windows har någorlunda stöd, men kan ställa till med en del problem som man bör känna till. Tidigare versioner av Internet Explorer har inget eller så dåligt stöd för CSS att det inte är värt att nämna. Samma sak gäller för Netscape före version 6.

Eftersom Internet Explorer är den webbläsare som just nu har flest användare får man ofta anpassa sig efter vad den klarar när det gäller den övergripande layouten. Därmed inte sagt att man inte kan eller ska ge de besökare som har en modernare webbläsare en ännu bättre upplevelse.

Alla webbläsare som används i dag har alltså inte det stöd för CSS som krävs för att man ska kunna få en webbplats att presenteras på ett grafiskt attraktivt sätt. Lyckligtvis är det bara några få procent som fortfarande använder så gamla webbläsare.

Det är viktigt att poängtera att dessa användare inte blir utestängda. På 90-talet var det populärt att använda webbläsarkontroller för att hänvisa den som använde ”fel” webbläsare (vanligtvis vad som helst förutom Internet Explorer/Win) till en sida som förklarade att man måste ”uppgradera” sin webbläsare för att bli insläppt.

Numera kan man hantera äldre webbläsare bättre. En stor fördel med att använda logisk, välstrukturerad XHTML är att sådana dokument är tillgängliga och användbara även utan stilmallar. Presentationen, utseendet, blir inte samma som i en modernare webbläsare, men innehållet finns där. I de allra flesta fall, för de allra flesta som besöker en webbplats, är innehållet viktigare än ytan. Därför är det bättre att stänga av CSS för webbläsare med dåligt stöd än att stänga ute besökare.

Det finns olika metoder för att göra detta. En av de vanligaste är att använda @import för att länka in sin CSS-fil. Netscape 4 och äldre förstår inte @import och kommer därför inte att läsa in CSS-filen. Det finns mängder av olika sätt att gömma CSS från webbläsare. Gemensamt för de flesta är att de bygger på buggar i webbläsarnas sätt att läsa CSS. Därmed finns alltid risken att en webbläsare uppdateras så att buggen som används för att gömma CSS från den är fixad, men inte det CSS-problem som var anledningen till att gömma viss CSS från just den webbläsaren. Ju mindre man använder dessa så kallade CSS-hack, desto bättre.

Man kan naturligtvis också göra en webbläsarkontroll på serversidan och använda den för att skicka olika CSS-filer (eller ingen alls) till olika webbläsare. Om man gör det måste man se till att hålla webbläsarkontrollen uppdaterad så man inte av misstag skickar fel CSS-fil till vissa när webbläsare uppdateras eller helt nya webbläsare släpps.

Läs mer:

Olika sätt att applicera CSS

Det finns flera olika sätt att applicera CSS på element i ett HTML-dokument.

Externt

Det innebär flera fördelar att ha alla CSS-regler i en eller flera separata filer. HTML-dokumenten blir mindre, CSS-filer lagras i webbläsarens cache-minne och behöver bara laddas ned en gång och man behöver bara ändra i en fil för att ändra presentationen för en hel webbplats. En extern CSS-fil kan se ut så här:

h1 {
    font-weight:bold;
}

Observera att det inte ska finnas något <style>-element i en extern CSS-fil.

Man kan länka en CSS-fil till ett HTML-dokument med ett <link>-element:

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

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

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

Inline

Genom att använda attributet style kan man applicera CSS direkt på ett HTML-element:

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

Man bör undvika detta eftersom det innebär att man blandar struktur och presentation.

Internt

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

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

Även detta bör undvikas, eftersom det bästa är att ha HTML och CSS i separata filer.

Läs mer:

Syntax

En CSS-regel består av en selektor och en eller flera deklarationer. Selektorn avgör vilket eller vilka HTML-element som påverkas av regeln. Varje deklaration i sin tur består av en egenskap och ett värde. Deklarationerna omges av { }, och varje deklaration avslutas med ; (semikolon).

En enkel CSS-regel ser ut så här:

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

I detta fall är selektorn p, vilket innebär att regeln kommer att påverka alla <p>-element i dokumentet. Regeln har två deklarationer, som tillsammans kommer att göra all text i <p>-element grön och fet.

För en mer detaljerad beskrivning av CSS-regler, se till exempel CSS Beginner's Guide, CSS from the Ground Up eller någon bra bok i ämnet.

Läs mer:

Överflödiga element och klasser

Vanliga misstag när man börjar använda XHTML och CSS är att använda onödiga XHTML-element, överflödiga klasser och extra <div>-element. Det behöver inte nödvändigtvis innebära att koden blir felaktig, men det motverkar en del av syftet med att separera struktur från presentation: att få enklare, renare kod.

Ett exempel på användande av överflödiga XHTML-element:

<h3><em>Rubrik</em></h3>

Om man vill att rubriken ska vara kursiv är det bättre att använda CSS för det:

h3 {
    font-style:italic;
}

Överflödigt användande av klasser kan se ut så här:

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

Det räcker med följande:

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

För att kontrollera element som ligger i div#main kan man sedan använda kontextuella selektorer i sin CSS-kod. I detta fall skulle det kunna se ut så här:

div#main p {
    /* regler */
}

Man kan i de flesta fall använda CSS för att få logisk XHTML att presenteras som man vill utan att behöva lägga till överflödig kod, men det finns fall där det kan vara värt lite extra kod för att skapa en viss presentation.

CSS-tips

Naturligtvis stöter man på vissa problem och svårigheter när man börjar använda CSS på allvar. En del kan bero på missförstånd, andra på otydliga specifikationer eller buggiga webbläsare. En samling goda råd som underlättar finns i CSS Crib Sheet, sammanställt av Dave Shea. Här är några av de viktigaste, fritt översatta till svenska, och ytterligare några som inte finns med där.

CSS-Layouter

Det finns mängder av exempel och steg-för-steg-förklaringar som visar hur man kan använda CSS för att skapa olika typer av layout. Ett råd är att man börjar med en enkel layout, lär sig hur den fungerar, och sedan ger sig på mer avancerade layouter.

Läs mer:

7. Tillgänglighet

Med tillgänglighet menas inte bara stöd för den med funktionshinder, även om det är där tyngdpunkten ligger. En tillgänglig webbplats fungerar bättre för alla, oavsett om man är funktionshindrad eller inte, och kan användas av fler personer med flera sorters webbläsare och apparater.

En relativt vanlig missuppfattning är att en webbplats som är tillgänglig för alla ser sämre eller annorlunda ut än en som inte är det. Det är helt felaktigt. Tillgängligheten behöver inte påverka utseendet över huvud taget.

Ett exempel på tillgänglighet som hjälper alla: Ett formulär som används för att anmäla intresse till ett seminarium ligger på en webbplats. I formuläret kan man välja om man vill gå på seminariet i Stockholm, Göteborg eller Malmö. Varje ortnamn ligger i anslutning till en radioknapp, som oftast visas som en cirkel som har en prick i mitten när den är vald. Om den som skapat formuläret inte har tänkt på tillgänglighet måste den som ser och använder en grafisk webbläsare klicka exakt på den lilla cirkeln för att välja ort. Om utvecklaren har tänkt på tillgänglighet kan man också klicka på ortnamnen. Vilket är enklast för den som ska använda formuläret?

Om man använder logisk, välstrukturerad XHTML är en stor del av jobbet gjort. För att få en första överblick av hur tillgängligt ett dokument är kan man titta på den i en textbaserad webbläsare som Lynx. Om innehållet behåller sitt sammanhang och är förståeligt där har man kommit en bit på vägen. Det är långt ifrån det enda man ska göra för att kontrollera tillgängligheten, men det är en bra början.

Här följer en genomgång av några teknologier som ställer särskilda krav på att man som utvecklare har kunskap om tillgänglighet.

Ramar

Många tycker att det är bekvämt att använda ramar för att dela in webbläsarfönstret i flera oberoende delar som består av separata dokument. Det kan vara användbart i vissa fall, till exempel i en intranätsapplikation eller liknande. På en publik webbplats finns det däremot många nackdelar med att använda ramar:

Dessutom gör man det onödigt svårt för sig. Ramar gör en webbplats mer tekniskt komplicerad.

Tabeller

Det är ganska vanligt att man tolkar ”använd inte tabeller för layout” som ”använd inte tabeller över huvud taget”. Så är det inte. Om det man ska märka upp är data som hör hemma i en tabell ska man använda en tabell. Däremot finns det många sätt att göra tabeller mer logiska och tillgängliga.

Läs mer:

Formulär

Formulär är ofta onödigt svåra att använda, delvis på grund av att de är uppbyggda på ett ogenomtänkt sätt, delvis för att den underliggande HTML-koden inte utnyttjar de element som finns till just för att göra formulär mer tillgängliga och användbara. Elementen <label>, <fieldset> och <legend> finns och är till för att användas.

En vanlig frågeställning är vad man ska använda för att bygga upp ett formulärs layout. Vissa säger att tabeller kan användas, andra menar att man ska använda CSS. Man kan använda den metod som passar bäst, men om man använder tabeller måste man se till att formuläret är begripligt och användbart även om man lineariserar tabellen det ligger i, det vill säga om man läser tabellen rad för rad med början i övre vänstra hörnet.

Läs mer:

JavaScript och cookies

Undvik att vara beroende av JavaScript. Fler än man kan tro har JavaScript avstängt, till exempel av säkerhetsskäl eller för att slippa popupfönster, eller använder en webbläsare utan stöd för JavaScript. Enligt TheCounter.com är andelen 6%, och enligt W3Schools.com är den 8%.

I de allra flesta fall tillför inte JavaScript något som hjälper besökaren. Det finns naturligtvis fall där man kan använda JavaScript på ett bra sätt. Ett exempel är formulärvalidering.

Observera att detta inte innebär att man ska undvika att använda JavaScript. Däremot innebär det att man bör undvika att göra en webbplats beroende av JavaScript för att fungera.

Samma princip gäller för cookies. Använd inte cookies på ett sätt som gör att webbplatsen slutar fungera om besökaren inte accepterar dem.

8. URL:er

Detta avsnitt har ingen direkt anknytning till webbstandarder, men är med eftersom hur en URL är konstruerad kan ha stor inverkan bland annat på hur väl en webbplats indexeras av sökmotorer och hur lättanvänd den upplevs av besökare.

Sökmotorer tycker inte om URL:er som är beroende av en querysträng för att visa rätt dokument. Det är ganska vanligt med sådana URL:er på webbplatser som dynamiskt hämtar sitt innehåll från en databas. En sådan URL kan se ut så här:

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

Det enklaste sättet att konstruera en bättre URL, både för sökmotorer och för människor, är att ändra den så att det ser ut som att den pekar på en katalog. En sådan variant av exemplet ovan skulle kunna se ut så här:

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

Sedan låter man webbservern tolka den nya URL:en så att den internt omvandlas till den ursprungliga, med querysträng. Se länkarna nedan för beskrivningar av olika sätt att göra detta på. En ännu bättre, men något mer komplicerad, variant är att helt ändra de URL:er som syns utåt så de blir begripliga:

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

Fördelarna med URL:er av denna typ är bland annat att det blir enklare för sökmotorer att indexera webbplatsen, enklare för människor att hantera URL:en, och man undviker att avslöja vilken serverteknik som används. Det gör också att det blir enklare att byta serverteknik om man skulle behöva det.

Om man ändå väljer att använda URL:er med querysträngar är det viktigt att se till att eventuella et-tecken, &, i querysträngen är konverterade till deras teckenreferens, &amp;. Om man inte gör det kommer flera webbläsare, precis som de ska, att se et-tecken som starten på en teckenreferens, och om texten som följer direkt efter et-tecknet motsvarar en sådan kommer webbläsaren att konvertera URL:en, och querysträngen förstörs.

En annan sak som är värd att nämna är att för de flesta webbplatser är det helt onödigt att använda en www-underdomän, och http://example.com/ bör användas i stället för http://www.example.com/. Mer information om detta finns hos no-www.org. Oavsett om man använder en www-underdomän eller inte, är det en bra idé att konfigurera webbservern så att den skickar all trafik till http://www.example.com/ och http://example.com/ till samma URI.

Läs mer:

9. Referenser

Här är ett urval av böcker, webbplatser och sändlistor som rekommenderas.

Böcker

CSS

Generellt om webbutveckling

HTML

Tillgänglighet

Webbstandarder

XHTML

10. Ordlista

CSS (Cascading Style Sheets)
Stilmallar som beskriver hur ett dokument ska presenteras.
HTML (HyperText Markup Language)
Används för att märka upp ett dokuments struktur.
Presentation
Den stil man ger ett dokuments innehåll. Oftast menar man utseende, men det kan också handla om hur ett dokument låter – alla använder inte grafiska webbläsare.
Struktur
De delar av ett dokument som är obligatoriska och den logiska uppmärkningen av dokumentets innehåll.
Tillgänglighet
En tillgänglig webbplats är åtkomlig och användbar för alla, oavsett vilken hård- eller mjukvara man använder och oavsett på vilket sätt man navigerar på webbplatsen.
Uppmärkning
När man märker upp ett dokument ger man struktur och betydelse till dokumentet och dess olika delar. I webbsammanhang används HTML och XHTML för detta.
Validering
Att validera ett dokument innebär att man kontrollerar att det följer de regler som finns för det språk som används i dokumentet. Man kan jämföra det med att kontrollera att en text är rättstavad och grammatiskt korrekt.
W3C (World Wide Web Consortium)
En organisation som utvecklar specifikationer, riktlinjer och verktyg för webben.
Webbstandarder
Webbstandarder är teknologier, upprättade av W3C och andra standardorgan, för att skapa och tolka webbaserat innehåll. Dessa teknologier är framtagna för att säkerställa hållbarheten för dokument publicerade på webben och samtidigt göra dessa dokument tillgängliga för så många webbanvändare som möjligt.
XHTML (Extensible HyperText Markup Language)
HTML anpassat för att följa de regler som gäller för XML.
XML (Extensible Markup Language)
Ett språk som liknar HTML, men är skapat för att man ska kunna beskriva data genom att själv definiera lämpliga element.

Kommentarer, frågor eller förslag? Kontakta mig.

© Copyright 2004-2008 Roger Johansson