Sådan arbejder du struktureret med CSS og HTML - Del 1
Udgivet den 07/01 - 2010
Tilbage i tidernes morgen skrev jeg et indlæg omkring god skik i udarbejdelsen af CSS. Meget er sket siden da - Jeg har tilegnet mig meget erfaring på ca. 1½ år – både omkring CSS og HTML, men her vil hovedsageligt være fokus på CSS.
På min arbejdsplads, Vestjysk Marketing, svinger jeg ofte pisken – måske ofte nok i følge nogle – i håb om bedre struktur og håndtering af både HTML og CSS. Det er ikke nogen relativ nem opgave, da vi som individer sjældent tænker 100% ens. Alligevel er der muligheder for at håndholde en vis ensformighed – dog ingen nem opgave – tvært imod.
- Struktureret CSS og HTML – del 1 (du læser)
- Struktureret CSS og HTML – del 2
Mange af de punkter, som jeg bragte op i mit førnævnte indlæg gælder stadigvæk. Men hvad er så kommet til siden da?
Opsæt de inviduelle styles alfabetisk
Førhen fulgte jeg en bestemt opsætning pr. element, hvor en række meget ofte brugte styles altid blev opsat i en bestemt rækkefølge. Metoden er ikke dårlig i den forstand, men ved at benytte dig af en alfabetisk opsætning skal du ikke huske nogen bestemt rækkefølge, men i stedet for benytte dig af viden, tilegnet tilbage i folkeskolen.
Eksempel:
#container {
background: #fff;
border: 1px #eeeeee solid;
height: 500px;
margin: 0 auto;
padding: 10px;
width: 500px;
}
Skab et synligt hieraki
Hvis du er god til at holde orden i dit stylesheet, så er et hieraki måske ikke nødvendigt. Alligevel kan et hieraki hurtigt hjælpe dig med at overskue, hvor tingene er placeret i forhold til hinanden. Vi er allerede bekendt med et hieraki, når vi arbejder med HTML eller programmering, hvor tingene rykkes ind så snart, de hører under elementet overfor – også kendt som parent i fagsprog. Derfor burde det være en rimelig smal sag at tilføre et hieraki til dit stylesheet.
Lad mig komme med en demonstration:
#container {
background: #fff;
border: 1px #eeeeee solid;
height: 500px;
margin: 0 auto;
padding: 10px;
width: 500px;
}
#header {
height: 100px;
padding: 10px;
width: 480px;
}
#mainnav {
border-bottom: 1px #eeeeee solid;
padding: 10px;
width: 460px;
}
Som det ses i eksemplet ovenfor, bliver henholdsvis #header og #mainnav rykket ind for at skabe en “illusion” af, at det er underliggende elementer. I dit hoved er det måske klart nok, at de 2 elementer har #container som parent, men det er måske ikke tilfældet for en kollega. Nu skal det siges, at dette eksempel er yderst simpelt, men det hjælper på at illustrere vigtigheden af et hieraki.
Med et hieraki hjælper du også andre til at se, hvordan strukturen er i HMTL’en uden at skulle til at kigge i andre filer. Herved gør du arbejdsprocessen væsentlig nemmere for alle, og samtidig dig selv i det lange løb. Med tiden arbejder man på en lang række webløsninger, og logisk nok er det svært at huske dem alle. Samtidig tager det ikke nogen betydelig ekstra tid at skabe et hieraki – specielt ikke – hvis du gør det fra starten af, så tid er ingen undskyldning, tvært imod.
Spar på benævnelserne
Når du refererer til underliggende elementer – children i fagsprog – er det ikke nødvendigt at nævne samtlige tags. Ganske vidst kan det hjælpe en smule på overskueligheden, hvis du tager aller tags med, men i det lange løb giver det bare en lang række unødige tegn, der fylder ekstra plads. Ja ja, nu tænker du sikkert noget i retningen af – ja, men så meget plads er det heller ikke. Nej, men lidt plads her og der, bliver til meget plads i alt – husk det ;)
Lad mig komme med 2 eksempler – henholdsvis “forkert” og “korrekt”:
Forkert: #mainnav ul li a {}
Korrekt: #mainnav a {}
Ved at benytte ovenstående metode opnår du stadigvæk det samme visuelle resultat, men du sparer en masse “overflødige” tegn. Det er kun nødvendigt at have den fulde sti med, hvis du har andre globale styles, der fungerer som parent.
Hold orden i grupperinger
Nogle gange samler man en række styles i grupperinger for ikke at genskrive de samme styles til en række elementer, der alligevel skal se nogenlunde ens ud. Mange vil måske bare skrive dem ud på en lang linie adskilt af et komma. En metode jeg egentlig selv altid har brugt, og kun for nyligt har ændret lidt på.
Lad mig komme med 2 eksempler – henholdsvis “forkert” og “korrekt”:
Forkert: #mainnav ul li a, #footernav ul li a, #sectionnav ul li a {}
Korrekt:
#mainnav ul li a,
#footernav ul li a,
#sectionnav ul li a {}
Igen får du skabt en væsentlig større overskuelighed af din gruppering – ingen grund til at gøre det besværligt for andre eller for den sags skyld dig selv ;)
Benyttelse af reset
Der findes en lang række forskellige måde at resette dit stylesheet på, men en af de mest populære kommer fra Eric Meyers. Et reset sparer dig for meget bøvl i dit arbejde med CSS. En række styles skal ofte defineres på mange elementer igen og igen, men vha. et reset, slipper du for at genskrive de samme styles igen og igen.
Personligt, så benytter jeg mig af en begrænset udgave af Eric Meyers reset, da jeg synes den store udgave skaber nye problemer. Jeg har eksempelvis oplevet problemer med tabeller – også selvom tabeller nærmest er tabu i min verden – men tabeller egner sig nu alligevel til deres retmæssige intention – tabulær data. Desmere kan den fulde udgave af Erics reset betyde, at man må definere en række styles på ny – sagt på en anden måde – skabe ekstra arbejde, hvilket ellers er ideen at bespare.
Generel opsætning af CSS til formularer
Hvis et website har en vis størrelse, så er der også en god chance for, at siden har op til flere formularer, og derfor kan det være en rigtig god idé at holde alle de nødvendige styles i en seperat fil (input.css). I filen er det ydermere en stor fordel at definere en række generelle styles til de forskellige formularfelter.
Hvis vi levede i en perfekt verden – dvs. uden Internet Explorer 6 – kunne vi benytte os af selectors, der udvælge specifikke formularfelter. Eksempelvis “Text” eller “Submit”, men uheldigvis understøttes denne mulighed ikke i førnævnte browser. Derfor har jeg i min metode valgt at tilskrive de forskellige felter en række klasser.
Eksempler:
.txtfield – <input type=”text” class=”txtfield”>
.btn – <input type=”submit” class=”btn”>
Med ovenstående mon ikke du forstår det store billede? Man opnår den samme mulighed som med selectors, men med understøttelse i Internet Explorer 6. Desmere er det nemt at tilføje ekstra klasser, hvis man skulle få behov herfor. Samtidig får man også en fil, der er velstruktureret og nem at overskue – hvis altså man forstår at holde orden.
Når du benytter dig af fremgangsmåden i eksemplet, så vil du i de gennerelle styles, øverst, definere det som går igen og igen – og efterfølgende kun lave de nødvendige korrektioner i de individuelle formularer rundt på pågældende hjemmeside. Jeg håber du kan se, hvor simpelt og struktureret det faktisk kan gå hen at blive.
Ps: Det skal iøvrigt nævnes, at jeg ikke ret ofte benytter mig af et hieraki i input.css, men det synes jeg med fordel sagtens kan gøres.
Benyt et framework
Ligesom med et reset, så er der mange tilbud ude på internettet. Logisk nok, så kan jeg ikke tillade mig at dele det framework, som vi benytter os af på min arbejdsplads. Alligevel vil du opleve, at min egen hjemmeside følger de samme metoder og principper.
Hvad end der virker bedst for dig, har jeg ikke noget endeligt bud på. En idé kunne dog være at kigge i dybden på de forskellige muligheder, som ligger til fri afbenyttelse på internettet. Som minimum kan du lære et par gode tricks til afbenyttelse i dit arbejde. Nedenfor finder du links til nogle af de mest kendte muligheder:
- Blueprint CSS
- Elements CSS Framework
- YAML CSS Framework
- YUI Grids CSS
- Boilerplate CSS Framework
- CleverCSS
- 960 Grid System
Gode links og vigtige artikler
Jeg har samlet et par gode links og artikler, der er gode at have i baghånden, hvis man skulle rende ind i et par problemer. Nogle giver en god baggrundsviden, mens andre er gode som opslagsværker. Uanset hvor dygtig man end måtte være, så er det svært at huske det hele.
- Opslagsværk til CSS og HTML
- CSS Box Design
- Fra tabeller til Div-elementer
- Webudviklerens store håndbog
- The Mystery of CSS Float Property
- CSS Differences in Internet Explorer 6, 7 and 8
- Mastering CSS Coding: Getting Started
- CSS Wishlist: New Ideas, Debates and Solutions
- Backgrounds In CSS: Everything You Need To Know
Mine 10 bud
Lad os her til slut kigge på mine 9 bud, der i kombination med alt ovenstående skulle hjælpe dig godt på vej – uanset om du er ny eller en garvet rotte i faget.
- Hold orden og struktur
- Undgå divitis (overforbrug af div-elementer)
- Undgå Classitis (overforbrug af class)
- Husk titler på links (øger brugervenligheden)
- Husk Alt på billeder (Kan hjælpe på SEO)
- Gør brug af Defintion Lists fremfor tabeller, hvis muligt. Tag eksempelvis et kig på mit CV
- Afslut dine HTML-tags (specielt Meta og Img)
- Hold dig til et sprog (eksempelvis Engelsk)
- Vær konsekvent i din navngivning
- Clear dine floats (tro mig, ellers kan det give grå hår)
Måske alle, der arbejder med webudvikling, burde følge mine bud? Ej, det er som udgangspunkt op til en selv, men de kan dog helt sikkert hjælpe dig med at arbejde mere målrettet og effektivt med CSS. Det vil også blive nemmere for dig fremadrettet, hvor du kan have behov for at lave tilretninger.
I mange situationer er det nemt at vælge den nemme vej over hegnet, men i det lange løb vil du nemt snuble nemt i dine egne snørebånd, fordi det pludselig tager væsentlig længere at lave tilretninger. Det bliver endda endnu værre, hvis en kollega skal ind at kigge på rettelser. Det er aldrig nemt at gennemskue, hvordan andre tænker, så hvis man følger en nogenlunde fast fremgangsmåde på arbejdspladsen, bliver det pludseligt langt nemmere. Du bør ikke kun tænke på dig selv, når du udfører dit arbejde.
Uanset hvor dygtig man end måtte være, så er det altid rart med input fra andre. Måske du har nogle forslag og ideer, der kan være med til at gøre arbejdet endnu mere struktureret. Samtidig vil det også være rart at høre din mening omkring mine metoder ;) Det kunne sagtens tænkes, at de trænger til en afpudsning i kanterne.
Kommentarer
-
Åhnej, første kommentar? Nu føler jeg et stort ansvar…
Specielt taget i betragtning, at jeg ikke kom helt igennem indlægget :P Men med mit begrænsede kendskab til CSS vil jeg påstå, at det du skrev, var godt! Min mening kan du så ikke bruge til noget som helst, men stadig ;)Se så at få fikset det, så min blogroll opdaterer dit seneste indlæg!
-
Gode tips. Især med hensyn til struktur i css koden.
Det er helt sikkert et område hvor jeg kan blive bedre. Især når jeg af og til skal kode flere tusind linjers css på et website.
P.S. Utrolig flot design du har på bloggen her. Måske det fedeste blog design jeg har set. Thumbs up for det.
/Henrik
-
@Bitten – Tak fordi du tog ansvaret og gav bolden op ;) Eller rettere, fordi du greb bolden – gav den egentlig selv op :P
@Henrik – Mange tak for de yderst fine ord omkring bloggen, dem sætter jeg stor pris på :D Omkring CSS, så tror jeg altid, man kan blive bedre – specielt når området ikke er stillestående.
-
Rigtig god artikel Michael.
Jeg kom lige til at tænke på en enkelt ting omkring et af dine 6 bud. Du skriver at du synes at man skal bruge definition lists i stedet for tabeller, de steder hvor det giver mening. Jeg ville egentlig bare høre hvorfor du har denne holdning?
Jeg har ikke selv nogle vilde præferencer for det ene eller andet, så jeg er faktisk bare nysgerrig. Og så har jeg aldrig rigtig fået gang i en fast brug af definition lists, så et par gode argumenter ville da helt sikkert få mine øjne op :) -
Godt indlæg Michael. For mig er det vigtigste som altid at man holder sig til en type orden, altså opstiller man alfabetisk, så gør det konsekvent, eller hvis man opstiller i den rækkefølge ting fx bliver brugt, så er det endnu vigtigere at det er konsekvent!
En ting jeg synes du mangler er fx navngivelse af elementer, mener bestemt man bør bruge sigende navne, og her er det igen vigtigt at holde en ensartede struktur, her er min foretrukne måde (css såvel som alt andet programmering helt sikkert camelCase, dvs sammensatte ord får stort begyndelsesbogstav som fx:
#pageContainer
man kan selvfølgelig også bruge underscore #page_container, der er jo frit valg, bare et spørgsmål om at være konsekvent igen. Give en definition ikke 100% mening, mener jeg også godt man lige kan smide en kommentar i sin CSS, det er jo ikke til at vidde om andre skal rode i den om et år eller 2.Rart at se dig tilbage i blogosfæren, dejligt med lidt ekstra spændende indhold at læse!
-
Først og fremmest tak, fordi i finder mit indlæg interessant og godt :)
@Kim – En af grundene munder nok ud i, at jeg har et mindre had til tabeller, men en definition list er bare nem og overskuelig at se på i kildekoden. Synes også de er nemme at arbejde med, hvorimod tabeller godt kan kræve sin tid. Men som nævnt, så er tabeller ikke banlyst, så længe de bruges til deres egentlig formål.
@Martin – det er også godt at være tilbage igen ;) Godt du nævner det med navngivelsen af sine elementer. Det er faktisk et vigtigt punkt, som jeg ikke lige fik tænkt over i forbindelsen med dette indlæg. Havde navngivelse med i mit første framework herude på arbejdspladsen, men faktisk ikke i version 2. Anyhow, så er det et punkt jeg skal have med i mine bud – ikke desto mindre. Faktisk, så benytter jeg mig af camelCase i dag, hvor jeg tidligere brugte underscore til adskillelse.
Men som du siger, så handler det i den grad om at være konsekvent, hvilket jeg selv prøver at tilstræbe bedst muligt – dog ingen nem sag, hvis man sidder på en arbejdsplads, hvor ikke alle umiddelbart har viljen hertil.
-
Godt indlæg. Der mangler måske lidt om navngivning. Jeg kan se i dit stylesheet, at der f.eks. er brugt ‘HeaderMestKommenteret’ og ‘HeaderProevOgsaa’ og ‘MyPage’.
Der bør man måske have et regelsæt for, om man kun bruger dansk eller engelsk eller om man må blande. Hierarkiet kan også bygges ind i navngivningen, og så er det vigtigt, om man kalder det ‘HeaderMestKommenteret’ eller ‘MestKommenteretHeader’, så relaterede definitioner hænger sammen.
Jeg arbejder som oversætter, og der har hver kunde sin helt egen style guide, som beskriver, hvordan man skal skrive, f.eks. om det skal hedde “Klik på Afslut i menuen Filer” eller “Klik på menuen Filer og derefter på Afslut” eller “Klik på Afslut i Filer-menuen”. Der står jo det samme, men som læser forstår man meget hurtigere teksten, hvis der bruges et ensartet hirarki/ensartet skrivestil.
Så navngivningen af elementerne i CSS bør også ensrettes, så eksempelvis alle headere starter med ‘header…’ eller så elementnavnet står først, f.eks. “navheader” i stedet for “headernav”.
-
Hej Johnny og velkommen til :)
Du har fuldstændig ret, navngivning er faktisk meget vigtig. Her følger jeg egentlig også nogle retningslinier. Burde lave en opdatering af indlægget, der medtager disse retningslinier.
Eksempelvis navngiver jeg også mine filer efter nogle retningslinier. Kalder alle billeder til knapper for “btn_en-tekst”, og har en side flere logoer skriver jeg “logo_firmanavn”.
Mit stylesheet er på bloggen er dog ikke 100% iorden, fordi jeg ikke havde hele layoutet færdigt, da jeg begyndte at sætte min side op. Det er absolut ikke den rigtige fremgangsmåde – det er kun “acceptabelt”, fordi det er min egen side.
Noget andet, jeg også burde tilføje noget var CSS Sprites, hvor man sammenfletter flere billeder i en fil.
Anyhow, mange tak for din feedback, som absolut er relevant :)
-
Sikke en god artikel du har skrevet her.
Der er rigtig mange brugbare ting, bl.a. vil jeg selv kigge lidt mere på definition lists.Der er dog en væsentlig ting, jeg synes der mangler.
Arbejder man meget struktureret, og derfor har mange indryk, linjeskift mm., så vil det teknisk set skabe en længere loade-tid.
Det er nok ikke noget man vil mærke på små sider, men kører man store communities og lignende (hvor strukturen måske er ekstra vigtig), så kan det muligvis mærkes. -
@Dennis – Velkommen til. Det er godt at høre, at du sætter pris på mit indlæg – det sætter jeg enorm stor pris på. Det giver absolut en stor mængde motivation for at skrive flere ;)
Du har ret i, at mange indtryk mv. skabe ekstra fyld i den endelig fil i form af plads. Her kunne man eventuelt vælge at komprimere sit stylesheet, hvilket dog skaber andre irritationsmomenter, hvis man jævnligt skal opdatere en given hjemmeside.
-
@Michael – Mange tak for velkomsten :-).
Det skal siges jeg aldrig har oplevet problemer med loade-tid, i de 7 års tid jeg har arbejdet med hjemmesider. Komprimering er måske en mulighed, især nu når Google også begynder at ranke søgeresultater efter loade-tid, jf. bl.a. http://blog.onlinemarketing.dk/google-loadtime-faktor.htmlMen det er jo et helt kapitel for sig selv. Du har i hvert fald ret i det hurtigt skaber irritationsmomenter.
-
Tak for linket Dennis, det var ny viden for mig.
Finder det faktisk meget interessant, fordi jeg altid går efter at optimere en side så vidt muligt – noget jeg dog halter lidt med her på siden, men skal i hvertfald gøre mit for at forbedre, hvor jeg kan :)
-
Super tip med det synlige hieraki. Jeg har aldrig tænkt over det, men det giver absolut mening. Med hensyn til frame.
@Dennis – CSS og JS bør altid så vidt muligt komprimeres, minimeres og flere filer bør samles i én, så den ekstra plads ovenstående tager behøver ikke at betyde noget. Mange CMS har et modul der tilbyder minify, komprimering og cache af css således at du kan have flere css filer liggende på serveren og at der hentes én samlet og komprimeret fil i HTML.
-
Hej Torben og velkommen til. Det er godt at høre, at du fundet mit indlæg brugbart. Det er super motiverende :D
Iøvrigt, så gav din kommentar også mig ekstra viden. Vidste faktisk ikke, at nolge CMS’er tilbyder et plugin eller har en funktion indbygget, der kan sammensmelte CSS og Javascript til hver sin individuel fil. Efterfølgende prøvede vi faktisk et plugin til Joomla på min arbejdsplads – Og det virkede ganske glimrende – medmindre man lavede opdateringer i sit CSS efterfølgende.
Du og i øvrige kan også se frem til en del 2, hvor jeg får en række øvrige punkter med, hvoraf nogle er nævnt i kommentarerne ovenfor.
-
Ja rigtig solid og gennemarbejdet indlæg. Der er flere ting her jeg vil prøve at tage til mig.
Er et fordærdeligt rodehovede til tider når det skal gå hurtigt med udviklingen, men kan sagtens mærke forskellen i de projekter hvor jeg har taget mig tiden til at få struktur på kode,html,css. alt bliver så meget nemmere for både mig selv og andre der skal ind i koden senere.Rigtig interessant blog du har, og den er nu smidt på min overvågningsliste :)
-
Claus, det er bare om at komme i sving ;) Og velkommen til iøvrigt.
Det glæder mig, at du har lyst til at følge med :D
-
Meget interessant artikel. Er dette “kun” en fordel for overskueligheden eller kan dette også gøre ens site/shops loadtid lavere?
Mvh. Peter
-
Hej Peter,
Struktureret html og css betyder ikke nødvendigvis det store for loadtiden, men derfor bør man stadig gøre sit for god og korrekt samt semantisk opstillet html.
Det bedste er at optimere på billederne og kald til serveren.
-
@Peter Munk – Denne form for strukturering har absolut ingen indflydelse på loadtid. Der kan dog være en afledt effekt af den bedre overskuelighed i og med at det gør det nemmere at kode mere effekttiv CSS, men det er stadigvæk kun millisekunderder der er at vinde
-
Hej Michael
Spændende indlæg omkring optimering og strukturering af CSS. Personligt er jeg dog af den skole, at man:
1) ikke skal bruge tiden på at opstille CSS pænt (det giver, efter min mening, mest mening i fx html, php, js, hvor det rent faktisk er hierakisk inddelt).
2) skal bruge den besparede tid fra punkt-1 på at skrive inline-CSS, som ikke kun er hurtigere at skrive, men også gør indlæsningstiden (som nævnt) på din side hurtigere. Måske er det marginaler, men som den mobile verden vinder ind, giver det mening at optimere i hovede og r**.
I mine CSS-filer er der ikke meget whitespace at finde, og sådan arbejder jeg nu engang bedst. Man kan jo altid søge i sine filer efter et givent element, og husker man ikke navnet, kan man på et splitsekund finde det via fx Firebug :)
Et andet tip (hvis man partout vil bruge tid på at indente sin CSS-fil) er, at man blot versionerer sine CSS-filer med et _ (fx styles_orig.css), og så kan man blot optimere sin produktions-fil, hvor whitespaces mv. er barberet væk.
Tid er penge, og workflow muss sein. ;o)
Kan i øvrigt afsløre, at michael-ostergaard.dk får 87 point i Page Speed Grade, så der er da lidt optimering at hente der endnu. Er selv i gang med at forsøge med CDN for ultimus serveroptimering (100/100) :)
Happy bloggin’ og optimizing ;o)
-
Mange tak for kommentaren, Tue.
Meget er sket siden dette indlæg blev tilbage i starten af 2010. Eksempelvis bruger jeg ikke indentation i min(e) css-filer længere.
Jeg er dog stadigvæk af den opfattelse, at der skal være en vis struktur i sin filer – specielt – ift. kolleger. Dog ikke en struktur ned til sidste milimeter, da man kommer langt med Firebug, som du selv nævner.
Igen, ser jeg ikke fordelen i inline css, specielt ikke ift. til kolleger. Eller best practice. Måske jeg misforstod dig?
Ps: Er bekendt med, at der er rum for lidt mere forbedring her på sitet ;)