Tips & tricks til bedre CSS og markup

Der er gået et år, siden jeg skrev indlægget Sådan laver du perfekt CSS, og jeg er i den tid blevet lidt klogere og fået noget mere erfaring, hvorfor en re-evaluering er på sin plads. Størstedelen af punkterne er stadig gældende, nogle er blevet ligegyldige og nye er opstået.

Min påstand er, at alle udviklere på et tidspunkt kommer til at støde på front-end arbejde herunder CSS og markup. Mange af de tungere drenge bryder sig ofte ikke om det, hvilket til tider resulterer i spaghetti kode! Om det er manglende interesse/viden eller bare arrogance, skal jeg ikke kunne sige. Ved at følge nogle simple principper kan det hele blive lidt sjovere og nemmere for alle parter, for de tunge drenge, for dem som er begejstret for det og sidst men ikke mindst for dem som skal vedligeholde det efterfølgende.

1. Markup før CSS

Lav altid dit markup før du begynder at style. Sørg for at den så vidt muligt er valid, og at den er semantisk opbygget. En god tommelfingerregel er, at ens markup skal give mening uden CSS.

2. Lav valid kode

Ligesom med dit markup skal dit CSS være valid. Hvis du er i tvivl, kan du validere dine stylesheets via W3's CSS validator. Mange undervurderer vigtigheden af valid kode, så længe det bare virker. Men ved ikke at have valid kode, kan man ikke være sikker på, at ens kode vil virke i fremtiden. Ved at følge en vis standard undgår vi kaos og monopolisme.

3. Normalisering

Normaliser altid dit stylesheet inden du går i gang. Forskellige browsere har forskellige default værdier for de forskellige elementer, hvorfor det til tider kan være umuligt at lave en side, der opfører sig ens cross-browser uden brug af reset. Hvor meget eller hvor lidt der skal resettes er en temperamentssag. Herunder er listet nogle eksempler:

1. CSS Reset Reloaded by Eric Meyer
2. Yahoo! UI Library: Reset CSS
3. CSS Global Styles Reset by Kyle Neath

Være opmærksom på at det korte og brugte reset: * { margin: 0; padding: 0; } er et misforstået reset. Det er "tungere" at renderer (især med store websider), da det definerer regler for hvert enkelt element i ens dokument og nulstiller alt, hvorfor det ikke er anbefalingsværdigt.

4. Navngivning

Navngivningen er vigtig og desværre også utrolig undervurderet. Uanset hvad du vælger så vær konsekvent. Hold dig evt. til engelsk, brug camelCaseMedLilleBegyndelsebogstav eller adskil ord med bindestreg (-)  og giv som udgangspunkt strukturelle navne frem for præsentationsmæssige.
Et strukturelt navn beskriver, hvad det er for et element, du vil henvise til frem for et præsentationsmæssigt navn, som beskriver, hvor elementet befinder sig på siden, eller hvordan det ser ud.

Præsentationsmæssige navne:

topNav, leftTopLogo, leftContent, redBoldLink

Strukturelle navne:

primaryNav, branding, mainContent, externalLink

De præsentationsmæssige navne låser elementet fast, hvorfor de skal undgås. Hvad nu hvis din top menu (#topNav) pludselig skal ligge til venstre for dit indhold? Der findes dog som altid undtagelser, hvor de præsentationsmæssige navne giver mening, som næste punkt vil illustrere.

5. Lav genanvendelig kode

Du er sikkert stødt på ordet "object-oriented CSS" også kaldet OOCSS?! Hvis ikke gør du det nu. Selve navnet, OOCSS, er en smule misvisende og forvirrede mig, da jeg første gang stødte på det. OOCSS er ikke, hvad man traditionelt vil betegne som objekt-orienteret programmering, OOP, men i stedet benytter man nogle af OOPs principper såsom polymorfi, abstraktion, arv mm.
Ideen bag OOCSS er at lave mindre og mere genanvendeligt CSS vha klasser. For en dybere redegørelse henvises til "opfinderens" hjemmeside, Nicole Sullivan.

Hvordan opnår man så genanvendeligt CSS? Først et eksempel på, hvordan man ikke skal gøre:

CSS:
#element1 a.btn {background-color:#000;color:#fff;}
#element2 a.btn2 {background-color:#000;color:#fff;}
#element1 a.btnWithBorder {background-color: #000;border:1px solid #ccc;color:#fff;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btnWithBorder">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn2">Knap 2</a>
</div>

Her indkapsler og fastlåser du din knap til et anchor tag samt id element og opnår derved redundans CSS samt kode, der ikke kan genbruges! Fjern afhængighederne og du har genanvendelig kode:

CSS:
.btn {background-color:#000;color:#fff;}
.border {border:1px solid #ccc;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btn border">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn">Knap 2</a>
</div>

Nu kan dine klasser bruges på alle typer af objekter og ikke kun anchor tagget:

<button type="button" class="btn">Knap</button>
<div class="btn">Knap</div>

6. CSS struktur

CSS strukturen bliver ofte glemt eller nedprioriteret, hvilket er ærgerligt, da den kan spare dig og andre for en masse spildtid! Et godt råd er, at man i sit team/udviklingsmiljø aftaler nogle strukturelle regler, så man nemt kan arbejde på tværs af hinandens projekter.  Eksempler på strukturelle regler kunne være:

• Stylesheets inddeles i afsnit, fx via sektioner eller selectors.
• En regels egenskaber opstilles i alfabetisk rækkefølge for at få et hurtigere overblik (#element { float: left; height: 250px; width: 250px; }).
• Man har et element pr linje kontra en egenskab pr linje i sit stylesheet.
• Hierarkisk inddeling.
• etc.

Hvis det skal have nogen effekt, er det vigtigt, at man er konsekvent. Man laver en ens struktur for at gøre udviklingen nemmere her og nu samt i fremtiden. Når man skal have sit projekt live bliver strukturen ligegyldig, hvorfor man altid skal minify sine stylesheets for at spare kb.

7. Stylesheets

Stylesheets skal altid være placeret i toppen fordi:

1. W3 dikterer, at stylesheets skal være i toppen (head), medmindre det er inline-styling.
2. Ved at placere stylesheets i toppen opnår man, at ens side loader progressivt, hvilket er vigtigt, hvis din side har meget indhold, eller brugeren sidder bag en langsom forbindelse. Siden viser indholdet så snart, det er klart, og brugeren har en indikation af, at siden er ved at loade. Denne indikation er meget vigtig for brugervenligheden. Hvis man derimod indsatte stylesheets nær bunden, ville man i mange browsere (eksempelvis Internet Explorer) miste den progressiv hentning og stå tilbage med en hvid blank side, da browsere blokerer renderingen for at forhindre at skulle gentegne elementer, der måtte ændre sig.

Der findes mange meninger omkring, hvordan du opnår den bedste performance samt struktur mht stylesheet inddelingen. Jeg er dog ikke stødt på en løsning, der kan bruges bestandigt og som hos så meget andet, mener jeg, at det skal vurderes fra projekt til projekt. Oftest ender jeg med et setup, hvor jeg samler mit reset jf. punkt 3, klasse objekter jf. punkt 5 og fællesregler (element styling, h1, h2 etc) i et stylesheet og, hvis nødvendigt, et side-specifikt stylesheet (internt eller eksternt), hvor regler der kun gælder for den aktuelle side er.

8. Brug shortcase

Brug shortcase, da det formindsker din kode og giver et bedre overblik. Et eksempel illustrer pointen:

#element { margin-top: 15px; margin-right: 10px; margin-bottom: 15px; margin-left: 10px; }

bliver til

#element { margin: 15px 10px; }

Du kan også bruge shortcase hos følgende egenskaber; background, border, font, list, margin, outline og padding. Dustin Diaz har skrevet en fremragende guide til emnet.

9. Spring mellemledet over

Som i den virkelige verden er det oftest billigst for forbrugeren, at mellemledet bliver fjernet, og det er det også hos CSS. Mellemledet er ofte ubrugeligt og fylder kun ekstra i dit stylesheet, hvorfor det skal fjernes. Der findes dog situationer, hvor du kan blive tvungen til at inkludere det men som udgangspunkt; fjern det:

#element ul li a span.class

bliver til

.class eller #element .class hvis man har behov for indkapsling

10. Undgå hacks

Hold dig fra at bruge hacks! Hvad enten det er * hack, _ hack eller lignende. Brug i stedet Conditional Comments til fx at indsætte et Internet Explorer 6 specifikt stylesheet.

<!--[if IE 6]>
<link type="text/css" href="ie6styling.css" rel="stylesheet">
<![endif]-->

Eller til at sætte en klasse på html tagget for derved at kunne style specifikt til en ønsket version af IE.

<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6"><![endif]-->
<!--[if IE 7 ]> <html lang="en" class="no-js ie7"><![endif]-->
<!--[if IE 8 ]> <html lang="en" class="no-js ie8"><![endif]-->
<!--[if IE 9 ]> <html lang="en" class="no-js ie9"><![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="no-js"> <!--<![endif]-->

11. Adskillelse

Markup og CSS er som Batman og Robin. De er fantastiske sammen, dog kan Batman fint klare sig alene, hvorimod Robin er ubrugelig uden Batman.
Man må aldrig begynde at sammensmelte markup og CSS og lave noget så uhyggeligt som inline styling. For at sikre fleksibilitet og overblik er det vigtigt at alt styling adskilles fra markup og kun lever i et stylesheet. Nu siger du sikkert, at der findes situationer, hvor inline-styling er eneste løsning, og ja det gør der, men brug det kun som sidste udvej, og ikke fordi du er doven.

12. Divitus, classitis og idikus

Undgå at få divitus, classitis eller idikus. Generelt for alle 3 sygdomme er, at man overforbruger. Man kan sammenligne det med et sønderjysk kaffebord, hvor der minimum er 14 forskellige kager, 7 bløde og 7 hårde, hvilket er helt unødvendigt. Derimod ville 1-2 kager fra hver kategori have været rigeligt.
Divitus er når man bruger for mange div'er. Mange nybegynder har en tendens til at smide en div rundt om alt:

<div id="mainHeader"><h1>Min overskift</h1></div>

Div'en er ikke nødvendig, og man kan i stedet skrive

<h1>Min overskrift</h1>

og så style på h1 i stedet for #mainHeader. Dog må man ikke være bange for at bruge div'er!  Jeg kan godt lide html5 tankegangen, som giver bedre overblik og en pænere struktur, hvorfor jeg til tider indkapsler hovedområder i en div med et sigende id!

Classitis og idikus minder meget om divitus:

<ul id="unsortedList">
  <li class="listItem firstItem">Item 1</li>
  <li class="listItem">Item 2</li>
  <li class="listItem">Item 3</li>
</ul>

Det er ikke nødvendigt at overklistre alle selectors med klasser og id'er:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Brug i stedet de elementer der allerede er til rådighed (ul, li) og, hvis IE6 også er død for dig, de smarte og hjælpefulde CSS selectors!

li:first-child   = Første li element.
ul > li          = Alle ul'ers børn der er li.
li + li          = Alle li'er der har samme forældre,
                   og hvor der kommer en li lige efter en li.

13. Vær god til matematik

Undersøgelser har vist, at personer med gode matematiske færdigheder har nemmere ved at programmere, hvilket også gavner, når man skal forstå, hvilken regel der er præcedens ved kollision. Fx kan et element have 2 regler der modsiger hinanden:

HTML:
<h1 class="h1">Header</h1>

CSS:
.h1{color:white;}
h1{color:black;}

Mange vil måske tro, at sidste regel altid er vigtigst, og at header teksten derfor vil være sort! Men hos CSS er der andre faktorer, der spiller ind. Først vægtes måden din styling bliver indlæst på:

1. prioritet: Inline styling
2. prioritet: Internt stylesheet
3. prioritet: Eksternt stylesheet
(4. prioritet: Browser default)

Dernæst vægtes attributterne:

li             {...}  /* a=0 b=0 c=1 -> specificity =   1 */
ul li          {...}  /* a=0 b=0 c=2 -> specificity =   2 */
ul ol li       {...}  /* a=0 b=0 c=3 -> specificity =   3 */
li.class       {...}  /* a=0 b=1 c=1 -> specificity =  11 */
ul ol li.class {...}  /* a=0 b=1 c=3 -> specificity =  13 */
#element       {...}  /* a=1 b=0 c=0 -> specificity = 100 */

hvor a repræsentere antal #id attributter, b antal klasse attributter og c antal tag elementer.  Jo højere tallet er, jo højere vægtning. I fornævnte eksempel vil header teksten være hvid, da klassen (.h1) vægtes med 10 point og tagget (h1) med 1 point.

14. Vær progressiv

I stedet for at udvikle til laveste fællesnævner, bør man være progressiv og anvende den nye teknologi, browsere løbende får, så længe siden stadig fungerer funktionelt hos laveste fællesnævner. Fx understøtter firefox bl.a. drag and drop af filer, hvor en bruger, der skal uploade en fil, kan dragge og droppe filen direkte ind i browseren og derved spare adskillige kliks. IE understøtter i skrivende stund ikke denne feature, hvorfor det selvfølgelig stadig skal være muligt at uploade en fil på den gammeldags måde. Her får brugeren med den bedre browsere bare en bedre oplevelse.

Et andet eksempel kunne være, hvor du har et element, der skal have runde hjørner og en gradient baggrund. I stedet for at skulle være afhængig af et stykke grafik eller flere, kan du lave runde hjørner samt gradient med CSS. Dette understøttes dog ikke i alle browser, nærmere bestemt IE, så når man udvikler efter laveste fællesnævner, bliver man nødt til at løse det med grafik, som gør siden tungere. Men nu er vi jo progressive, og derfor vælger vi den lettere og elegante CSS løsning, og lader brugerne af IE se et firkantet element med fast baggrund, og alle andre et lækkert rundt element med gradient. Siden kan stadig bruges af IE brugere, og IE brugerne ser stadig samme indhold, som andre brugere. Dog kan designere være tunge at danse med, og ofte kan det ende i et kompromis, hvor man bruger CSS3 de steder, der understøtter det og ellers grafik (IE).

15. Kend dine elementer

Som med alle programmeringssprog er det en god ide at kende til basis funktionaliteterne. Nogle gange er området dog så stort, at en del erfaring er påkrævet. CSS har derimod et overkommeligt antal basis elementer, der derfor gør det hurtigere og nemmere at få et overblik og derved at kunne vælge de rigtige elementer i den rigtige situation. Lær elementerne at kende før du går i gang, float vs. position, display vs. visibility, tabel vs. div etc.

16. Centrer med margin

Centrer med margin: 0 auto; i stedet for fx at fastkode en fast padding i venstre side. For at centrer med margin skal du definere en bredde:

#element { margin: 0 auto; width: 800px; }

17. Vær doven

Sidste punkt som i øvrigt gælder programmering generelt er, at man skal være doven. Der findes et utal af udviklere, som allerede har haft de problemstillinger, som du støder på, hvorfor det vil være fjollet ikke at benytte sig af deres viden og erfaringer. Genbrug dine og andres komponenter og brug de erfaringer, der allerede er tilgængelige. I CSS støder man på mange lignende problemstillinger, hvorfor man nemt kan ende som Sisyfos!

SLUT

Det var mit bud på, hvordan man ved hjælp af nogle simple principper, opnår bedre og mere overskueligt CSS og markup. Vigtigst af alt er, at man er konsekvent hele vejen igennem og tro mod kode standarderne. Sammen kan vi gøre verden til et bedre sted!

P.S. Har jeg glemt noget, eller er du bare dybt enig/uenig så smid gerne en kommentar.