Den HTML och CSS du fått lära sig än så länge har resulterat i ganska tråkiga, dokument-liknande sidor. Detta är kanske fullt tillräckligt i en del fall, men oftast vill man bryta det ordbehandlarliknande resultatet och kunna positionera element lite mer utförligt. Man vill kanske lägga en meny brevid sitt textinnehåll, eller åstadkomma något enklare som att få en bild att ”flyta” till höger om texten. I detta kapitel kommer du få se två förlegade metoder och lära dig en modern metod för att göra just dessa saker.
Sedan HTML kom till 1993 har utvecklingen gått på många olika håll, och under tiden har man använt ett antal olika metoder för att bryta den dokumentlika strukturen HTML hade från början. Den första tekniken, ramar, föddes av ett behov att kunna ha en och samma meny och titel på alla undersidor, utan att behöva synkronisera alla filer. Idag görs sådant med skript på serversidan.
Man kunde dessutom använda ramarna för att placera olika delar av sidan i ett slags rutnät. På så sätt kunde man placera en meny på höger/vänster sida, ett sidhuvud i toppen och en sidfot på botten. Man kunde sedan komma undan med att bara uppdatera mittendelen (den del med allt innehåll), vilket sparade mycket bandbredd i en tid då många satt på 28.8k-modem.
Tyvärr skapade ramar även en rad oförutsedda problem, som först på senare tid uppmärksammats:
Ramar var mycket användbara under internets barndom, innan serverspråken utvecklats ordentligt och när uppkopplingarna fortfarande var långsamma. I dagsläget är ramar fullständigt förlegade och HTML5-specifikationen rekommenderar man andra lösningar:
Använd antingen
iframe
och CSS istället, eller serverinkluderingar för att generera fullständiga sidor med de olika delarna inlagda. (Fritt översatt.)
När serverspråken till slut utvecklats insåg många att man kunde använda dessa istället för ramar för att inkludera menyer och dylikt. Man sökte andra metoder för att kunna placera sina element på sidan, och med rutnätstänkandet från ramarna i färskt minne beslöt många sig för att gå över till en mycket liknande konstruktion: tabeller.
Tabellerna inkluderades i HTML under dess tidiga år då det var tänkt att man skulle kunna använda HTML för att publicera vetenskapliga rapporter; tabeller är så klart en mycket viktig konstruktion i sådana sammanhang. Med tiden började folk dock använda dem på andra sätt; de "klippte" upp sina layouter i rektangulära bitar och använde tabeller, speciellt dess attribut colspan
och rowspan
för att tvinga de rektangulära bitarna till rätt plats.
Med tabeller utan kanter kunde man enkelt dölja det faktum att det var just tabeller. Besökare märkte inget, utvecklare tyckte att det var praktiskt och enkelt, alla var nöjda. Tyvärr blir en lösning inte bra för att man döljer fulhacket — att använda tabeller till layout ger upphov till många problem:
<em>
innebär att texten ska betonas. Lägger man design i tabeller kastar man ut all semantik genom fönstret.HTML5-specifikationen avråder starkt från att använda tabeller till layout:
Tabeller får inte användas till layouter. Historiskt sett har många webbutvecklare missbrukat tabeller för att kontrollera sin layout. Detta är dåligt, eftersom verktyg som försöker extrahera tabulär data från sådana dokument får fram väldigt konstiga resultat. Mer specifikt får användare av screen readers väldigt svårt att navigera sidor som använder tabeller för layout. (Fritt översatt)
Notera dock att tabeller inte är bara dåliga; man bör definitivt använda tabeller för att presentera tabulär data, eftersom det är därför de inkluderats i HTML. Roger Johansson förklarar det hela:
Det är ganska vanligt att folk tolkar ”använd inte tabeller för layout” som ”använd inte tabeller alls”. Det är inte så det ska tolkas. Om det du skriver är tabulär data så hör det hemma i en tabell, och då är det en tabell du ska använda.
Under ett av de sista Seybold-seminarierna 2003 hölls en mycket viktig presentation som satte en boll i rullning. Presentationen försökte presentera ett antal mycket starka argument till varför man skulle använda CSS, en då ganska oanvänd teknik, istället för tabeller för att bygga upp sin layout. Denna boll har nu varit i rullning i många år, och med den har CSS fått en rejäl knuff i sin utveckling. Idag utvecklas CSS3, som kommer att ge helt fantastiska möjligheter för designers och utvecklare. Det är denna teknik som används idag, och som kommer användas ett bra tag framöver. Det är denna teknik du nu ska få bekanta dig närmre med.
Har vi ett kapitel om det fantastiska i CSS3, t.ex. @font-face
?
Kommer du ihåg början av boken, då vi presenterade struktur- och presenationslagren? Nu ska du få se varför man väljer att separera dessa två. Vi börjar med att sätta ihop en ”typisk” sida, bestående av ett par grundläggande delar: sidhuvud, meny, innehåll och sidfot. I detta kapitel kommer vi att använda oss av de nya HTML5-elementen header
, nav
, article
och footer
till respektive del av sidan. Vi börjar med att sätta ihop struktur-delen till exemplet, som vi sedan kommer använda CSS på:
Som du säkert kan gissa dig till så utgör alla de ”äldsta” elementen (de som ligger närmst roten av elementträdet) var sin grundläggande del av sidan. Detta innebär att vi kan positionera dessa på det sätt vi önskar. Utan CSS ser vårt dokument ut så här:
Denna HTML kommer vi använda utan modifikation i alla de layouter vi nu ska presentera för dig; det är därför man separerar struktur och presentation — man behöver bara ändra på ett ställe om man vill ändra presentationen eller strukturen).
För små sidor, enkla dokument eller liknande saker behöver man oftast inte någon komplex layout. Det kan räcka med att lägga en fin liten ram runt menyn, introducera några snygga typsnitt och centrera sidan. Det är det vi ska göra nu.
För att centrera sidan krävs det ju så klart att sidan är smalare än fönstret. Normalt sett så är alla blockelement 100% breda, dvs. de fyller hela sin förälders bredd. För vårt dokument innebär det att alla våra element fyller hela fönstret. I stora fönster gör detta textraderna väldigt långa och svårtlästa; textrader ska helst inte vara mer än cirka tolv ord långa, vilket är mellan 30 och 40 tecken.
Hur vet vi hur brett ”ett tecken” är då? Jo, lyckligtvis har man i CSS inkluderat enheten em
, och 1em
är då så långt som bredden på gemena bokstaven ”m” i det typsnitt som används. Detta är en hyfsat bra approximation till bredden av ett tecken. Denna enhet kan vi använda tillsammans med CSS-attributet width
för att sätta en lämplig bredd på de grundelement vi har i HTML-dokumentet.
När vi sedan vill centrera elementen finns det ett trick (som endast fungerar på blockelement): om man sätter vänster- och högermarginalen på ett element till auto
, så kommer webbläsaren försöka balansera elementet så att dessa två blir lika stora. Voilá, centrering!
Bra, nu har vi en begränsad bredd på alla element, och dessa är centrerade. Nu vill vi kanske separera de olika elementen lite mer stilmässigt för att ytterligare visa att de är olika saker. Vi börjar med vårt sidhuvud.
Först och främst vill vi centrera texten i vårt sidhuvud; det kommer att se snyggare ut. För att göra detta använder vi så klart CSS-attributet text-align
, och sätter det till center
:
Nu vill vi dessutom minska storleken på vår tagline; den är ju löjligt stor! Givetvis har CSS även en egenskap för detta, nämligen font-size
(mer om dessa textförändrande attribut får du veta i ett annat kapitel, ”Typografi på webben”). Vi sätter den till 100%
, dvs. 100% av storleken på förälderns text (vilket i vårt fall ger normal textstorlek):
Nu ser vårt sidhuvud lite bättre ut, och det är dags att hoppa på menyn. Som du kanske redan märkt så använder vi en oordnad lista för att skapa en sorts meny — detta är mycket vanligt. Vi vill dock inte ha några listpunkter i vår meny, och i det här fallet vill vi dessutom att elementen lägger sig på rad istället för på höjden. Det första problemet löser vi enkelt med attributet list-style-type
. Det andra kräver att vi använder CSS för att göra om våra li
-element från blockelement till inline-element. För detta använder vi attributet display
.
Attributet display
används för att ändra grundläggande beteenden hos element. Det kan ta många värden, men de viktigaste är relativt enkla att komma ihåg:
block
får elementet att visa sig som ett blockelement: radbrytning sker före och efter elementet, och det kan ha både bredd och höjd. Några element som har denna stil från början är h1
, p
och blockquote
.inline
får element att ”följa med” texten. De kan inte ha höjd eller bredd, och kan inte flyttas runt som blockelementen. Element som strong
, a
och img
är inline-element.inline-block
är ett specialvärde som får elementet att bete sig som en blandning mellan inline- och blockelement: det kan ha bredd och höjd, men det sker inga radbrytningar runt det. Inga element har denna stil från början.none
gör att elementet helt enkelt ignoreras. Det visas inte på sidan och påverkar inte några andra element över huvud taget. Kan användas för att dölja element.Vi vill ge våra li
-element värdet inline-block
så att de läggs på rad men så att vi ändå kan ge dem en bredd. På så vis kan vi skapa en ”låda” med en specifik bredd, centrerad text, padding
och en fin liten bakgrund så att listelementen ser mer ut som knappar:
Nu kommer menyvalen att lägga sig brevid varandra, men justeras till vänster. Det vill vi ju inte! Ingen fara; vi kan ju centrera ul
-elementet, så centreras hela menyn. För att göra detta sätter vi först en bredd på elementet — en bredd på 20em bör räcka för att alla tre menyelementen ska få plats på bredden. Vi måste även ta bort den padding
som ul
-elementet har från början:
Vi väljer att låta själva artikeln se ut som den gör, och ändrar bara sidfoten genom att minska textstorleken och centrera:
Resultatet är en klar förbättring (nåja, förändring) från vårt fullständigt stillösa dokument. Kom ihåg att vi gjort detta endast genom att ändra presentationslagret — all HTML ser fortfarande likadan ut!
TODO: En annan layout
…
Som du kanske märkt så ändrar man ganska mycket på de stilar som redan är definierade av webbläsaren. Vissa har därför fått för sig att det är bra med så kallade CSS-resets, som ”nollställer” all CSS och tar bort webbläsarens förinställda attribut. På senare tid har detta fått en del negativ uppmärksamhet, och vi avråder starkt från att använda CSS-resets.
Webbläsarens förinställningar finns där av en anledning; de definierar stilar som webbutvecklaren inte tänker på, lägger upp en grundläggande typografistil så att dokument är läsbara även utan CSS och hjälper ofta till när du bygger upp din egen layout. Istället för att nollställa allt så bör man använda webbläsarens stil där den passar, och ändra den vid de tillfällen den inte gör det.
Detta får som konsekvens att alla sidor inte kommer se exakt likadana ut, men i stort sett kommer de att ha samma utseende; det kommer att skilja på några pixlar hit eller dit. Man får helt enkelt fråga sig om varje sida måste sidan se likadan ut i alla webbläsare, och sedan motarbeta webbläsaren eller låta den göra halva jobbet utifrån det. Du kan ju fundera på vad som tar mest tid.