Webboken

Om att bryta lineariteten

Nu och då: Hur flyttade man runt sina element?

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.

En kort prolog om hur man gjorde förr

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.

1993–1998: Ramar

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.)

1998–2004: Tabeller

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:

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.

2004–nu: CSS-layout

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?

CSS — ett kraftfullt verktyg

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å:

<header>
    <h1>En enkel sida</h1>
    <h2>En tagline till sidan</h2>
</header>
<nav>
    <ul>
        <li><a href="#">Hem</a></li>
        <li><a href="#">Köttbullar</a></li>
        <li><a href="#">Tellurianer</a></li>
    </ul>
</nav>
<article>
    <h1>En enkel artikel</h1>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
    <p>Nam libero tempore, cum soluta nobis est eligendi optio, cumque nihil impedit, quo minus id, quod maxime placeat, facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet, ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat…</p>
</article>
<footer>
    <p>Senast uppdaterad <time datetime="1789-07-14">för en herrans massa år sedan</time>.</p>
</footer>

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:

HTML-dokumentet ser mycket tråkigt ut innan några CSS-stilar tillämpats
HTML-dokumentet utan några CSS-stilar

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).

Den enklaste layouten: centrering

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!

header, nav, article, footer {
    width: 35em;
    margin: 1em auto;
}

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:

header {
    text-align: 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):

header h2 {
    font-size: 100%;
}

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:

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:

nav li {
    list-style-type: none;
    display: inline-block;
    width: 6em;
    text-align: center;
    background: #eef;
    padding: .25em 0;
}

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:

ul {
    padding: 0;
    margin: 0 auto;
    width: 20em;
}
Till sist ramar vi in hela menyn med en fin, vag dubbelram. Det kanske inte blir världens snyggaste meny, men det fungerar för tillfället:
nav {
    padding: .25em;
    border: 4px double #ccc;
}

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:

footer {
    font-size: smaller;
    text-align: center;
}

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!

Med den nya stilmallen ser vårt dokument betydligt bättre ut.
Vår nya, centrerade ”layout”.

Något mer avancerat: meny till vänster

TODO: En annan layout

Redundans och CSS-resets

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.