Translations of this article are available.
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.
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.
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.
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.
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.
Dokument från W3C om hur man kan förbättra kvaliteten på sin webbplats.
Mission statement för The Web Standards Project.
The Web Standards Project har skrivit en grundlig förklaring av webbstandarder och varför det är bra att använda dem.
Artikel på Netscape DevEdge om hur företag kan tjäna på att använda webbstandarder.
Artikel från The Web Standards Project riktad mot företags marknads-, kommunikations- och IT-avdelningar.
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>.
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.
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.
En presentation som hölls på Seyboldmässan 2003. Se även Anton Andreassons svenska översättning: Varför tabeller för layout är dumt.
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.
Man märker upp rubriker med <h1>, <h2>, <h3>, <h4>, <h5> eller <h6> beroende på nivå, där <h1> anger den översta nivån.
<h1>Dokumentrubrik</h1> <h2>Underrubrik</h2>
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.
<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 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.
<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>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>
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.
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.
<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">”The presentation of phrase elements depends on the user agent.”</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>”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.”
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.
<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.
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).
<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> </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>
| 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.
En mycket bra resurs för att förstå hur man kan resonera för att komma fram till hur man ska märka upp något logiskt.
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:
Använd gemener för element och tumtecken runt attribut: Alla namn på element och attribut måste skrivas med gemener. Dessutom måste alla attributvärden omges med tumtecken.
Fel: <A HREF="index.html" CLASS=internal>
Rätt: <a href="index.html" class="internal">
Avsluta alla element: I HTML är det tillåtet att låta bli att avsluta vissa element. De avslutas då automatiskt när nästa element börjar. Så är det inte i XHTML. Alla element måste avslutas, även de som inte har något innehåll, som till exempel <img>.
Fel: <li>Punkt 1Rätt:
<li>Punkt 1</li>
Fel: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Rätt: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Fel: <br>
Rätt: <br />
Fel: <img src="bild.jpg" alt="">
Rätt: <img src="bild.jpg" alt="" />
Ge alla tomma attribut ett värde: I HTML finns vissa attribut som inte behöver ges ett värde. Detta gäller inte i XHTML.
Fel: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Rätt: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Använd inga förkastade element: Vissa element och attribut som är tillåtna i HTML 4.01 Transitional och XHTML 1.0 Transitional är förkastade, det vill säga de ingår inte längre i specifikationen, i XHTML 1.0 Strict (och i HTML 4.01 Strict). Dit hör till exempel <font>, <center>, alink, align, width och height (på vissa element) samt background.
The Web Standards Project frågar W3C om man ska använda HTML eller XHTML och varför.
Artikel på A List Apart om övergången från HTML till XHTML.
Bra förklaring av hur XHTML och CSS används.
W3C förklarar skillnaderna mellan XHTML 1.0 och HTML 4
Sammanställning av skillnaderna mellan XHTML 1.0 Strict och Transitional
The Web Standards Project frågar W3C om vilken MIME-typ man ska använda för HTML respektive XHTML och varför.
En sammanställning av vilka MIME-typer som bör användas för XHTML-dokument.
HTML Dogs guide till vilka element och attribut man inte bör använda.
Ett dokument om MIME-typer och hur man kan använda olika skriptspråk på serversidan för att känna av vilken MIME-typ som ska skickas.
W3C förklarar hur mime-typer fungerar i XHTML-sammanhang.
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">
Artikel på A List Apart om hur och varför man ska använda Doctype.
Sammanställning av hur webbläsare som har Doctype Switching hanterar olika DOCTYPE-deklarationer.
W3C:s officiella lista över korrekta Doctype-deklarationer.
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.
The Web Standards Project frågar W3C om hur man ska ange vilken teckenkodning ett dokument använder.
Artikel om olika teckenkodningar.
Förklaring av olika sätt att använda specialtecken i HTML-dokument.
En förklaring av hur man väljer och anger teckenkodning.
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.
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.
Eric Meyer beskriver fyra sätt att gömma CSS från vissa webbläsare.
Sammanställning av en mängd olika sätt att gömma CSS från olika webbläsare.
Dokument som diskuterar olika sätt att förbättra upplevelsen för den som använder en modern webbläsare.
Det finns flera olika sätt att applicera CSS på element i ett HTML-dokument.
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>
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.
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.
Förklaring av CSS-import, mediatyper med mera.
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.
Dave Shea har med hjälp av sina läsare sammanställt en lista med praktiska råd och tips för CSS.
John Gallant och Holly Bergevin förklarar hur man skriver kompakt CSS.
Mycket bra förklaring av olika CSS-selektorer och hur de fungerar.
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.
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.
Börja med att validera: Vid felsökning, börja med att validera både HTML och CSS. Många problem kan orsakas av felaktigheter i koden.
Utveckla och testa CSS i den mest avancerade webbläsaren först – testa sedan i andra webbläsare: Om man använder en äldre webbläsare med en dålig och/eller felaktig implementation av CSS för att testa när man utvecklar kommer koden att vara anpassad efter detta. När man sedan testar i en modernare webbläsare är risken stor att den kommer att bete sig annorlunda. Det är bättre att börja med den bästa webbläsaren och sedan anpassa CSS-koden för sämre webbläsare.
Förstå hur ett elements bredd och höjd beräknas: För att få fram ett elements faktiska bredd eller höjd adderar man dess padding
och border till dess width eller height. I Internet Explorer 5.*/Win ingår padding och border i stället i den width eller height som angetts.
Antag att man har följande CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
Den totala bredden blir 360px.
10px + 20px + 300px + 20px + 10px = 360px
I Internet Explorer 5.* blir den totala bredden 300px, och innehållets bredd 240px.
300px - 10px - 20px - 20px - 10px = 240px
För att komma runt detta problem kan man antingen använda ett CSS-hack för att ange olika värden till de webbläsare som gör rätt och de som gör fel, eller så kan man undvika att ange både width och padding eller border för ett element.
För en grundlig förklaring av denna så kallade boxmodell, se dokumentet Box model.
Ange enheter för numeriska värden: CSS kräver att man anger enheter för värden på höjd, bredd, tjocklek, textstorlek och så vidare. Ett undantag är om värdet är 0 (noll). Då behövs ingen enhet, eftersom noll är noll oavsett vilken enhet det är.
Förstå hur float fungerar: Float-begreppet kan vara svårt att förstå, men det är viktigt att lära sig hur det fungerar eftersom man har stor nytta av float när man bygger CSS-baserade layouter. Några mycket bra beskrivningar av hur float fungerar är Containing Floats, Floatutorial och Float: The Theory.
”LoVe/HAte”: Pseudoklasser för länkar ska specificeras i ordningen Link, Visited, Hover, Active.
”TRouBLed”: När man använder kortformen för att specificera margin, padding eller border för ett element börjar man med den övre och går medsols: Top, Right, Bottom, Left.
Namnge klasser och ID efter funktion, inte efter utseende: Om man skapar en klass som heter .smallblue och sedan behöver göra texten stor och röd kommer klassnamnet att vara förvirrande. Det är bättre att använda funktions- eller strukturbeskrivande namn som .copyright eller .important.
Gemener och versaler är olika: CSS gör skillnad på gemener och versaler när det gäller värden på HTML-attributen class
och id (se CSS2 syntax and basic data types).
När det gäller elementnamn är det skillnad på versaler och gemener med XHTML skickat som XML, men inte med HTML eller XHTML skickat som text/html.
Kontrollera ID: Bara ett element per dokument kan ha ett visst ID, medan hur många element som helst kan ha samma class.
Använd endast tillåtna tecken i namn: Värden på class och ID får endast innehålla tecknen [A-Za-z0-9] och bindestreck (-). De får inte börja med ett bindestreck eller en siffra (se CSS2 syntax and basic data types).
Kommentera rätt: Kommentarer i CSS börjar med /* och slutar med */:
/* Detta är en kommentar */
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.
Ett exempel på hur man kan skapa en enkel layout med sidhuvud, två spalter och sidfot.
Samlingssida med länkar till information om olika CSS-layouter.
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.
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:
robots.txt att sökmotorer inte ska indexera undersidor. På andra webbplatser använder man JavaScript för att skicka alla besökare från sökmotorer till startsidan. Båda dessa metoder kan fungera, om syftet är att man vill ha färre besökare.Dessutom gör man det onödigt svårt för sig. Ramar gör en webbplats mer tekniskt komplicerad.
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änkar till artiklar som beskriver hur man bygger tillgängliga tabeller.
Artikel om hur man använder tabeller för data.
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.
Artikel om tillgängliga formulär på WebAIM.
En artikel som går igenom grunderna för hur man bygger bättre och mer tillgängliga formulär.
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.
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, &. 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.
Förklaring av problemen med vissa sorters URL:er och olika sätt att förbättra sina URL:er.
Artikel om varför det är bra att avsluta URL:er med /.
Samling av länkar till artiklar och beskrivningar som förklarar hur och varför man ska tänka på hur sina URL:er ser ut.
En längre förklaring av problemen som kan uppstå om en querysträng innehåller okonverterade et-tecken, och en demonstration av vad som kan hända.
Här är ett urval av böcker, webbplatser och sändlistor som rekommenderas.
Projektbaserad bok som förklarar hur man kan använda CSS i praktiken.
Uppföljaren till Eric Meyer on CSS.
Referensbok som går igenom CSS-rekommendationerna.
Grundlig genomgång och förklaring av vad tillgänglighet innebär och hur man bygger tillgängliga webbplatser.
W3C:s officiella specifikation.
W3C:s officiella specifikation.
En sändlista som diskuterar CSS och dess praktiska tillämpningar.
En sändlista på svenska där man diskuterar CSS och angränsande frågor.
En webbplats som har samlat riktlinjer för hur man skapar så bra webbplatser som möjligt med HTML och CSS.
Samma HTML, olika CSS. En mängd exempel på hur CSS kan användas för att ge ett och samma dokument en mängd olika utseenden.
Flera mycket välskrivna artiklar som förklarar hur man använder CSS.
Artiklar, demonstrationer, webbläsarbuggar med mera.
Regelbundet publicerade artiklar i ämnen som rör design, utveckling och betydelse av webbinnehåll, med särskild fokus på tekniker och fördelar med att använda webbstandarder.
En sändlista för den som bygger webbplatser. Det mesta som har med webbdesign och webbutveckling diskuteras på listan.
W3C:s officiella specifikation.
En webbplats som har samlat riktlinjer för hur man skapar så bra webbplatser som möjligt med HTML och CSS.
Joe Clarks bok i onlineformat.
Mark Pilgrims bok om tillgänglighet.
W3C:s officiella riktlinjer för tillgängliga webbplatser.
W3C:s samling av information om verktyg för att utvärdera och förbättra webbplatsers tillgänglighet.
”The Web Standards Project is a grassroots coalition fighting for standards that ensure simple, affordable access to web technologies for all.”
En webbplats vars mål är att hjälpa webbutvecklare förklara för kunder att webbstandarder är ett önskvärt val. Se till exempel dokumenten What Every Web Site Owner Should Know About Standards: A Web Standards Primer och The Way Forward with Web Standards.
Dave Sheas vägledning för den som vill börja använda webbstandarder.
W3C:s officiella specifikation.
En webbplats som har samlat riktlinjer för hur man skapar så bra webbplatser som möjligt med HTML och CSS.
Kommentarer, frågor eller förslag? Kontakta mig.
© Copyright 2004-2008 Roger Johansson