I nedan innehållsförteckning kan ni se vad jag tänker gå igenom och ta upp i detta inlägg.

  1. Introduktion – Vad är Responsiv Webbdesign?
  2. Tillvägagångssätt – Mobile-First vs. Mobile-Last
  3. Tekniker och kodningsmetoder – ”Enhetsspecifikt” vs. ”Breaking-points” (för & nackdelar)
    1. Breaking-points kodningsmetoden
      1. Att tänka på
      2. Nackdelar?
      3. Fördelar jämfört med Enhetsspecifika kodningsmetoden
      4. Hur kodningsmässigt?
    2. Enhetsspecifika kodningsmetoden
      1. Nackdelar?
      2. Fördelar?
      3. Hur kodningsmässigt?
    3. Verklighetsbaserat exempel
  4. Responsiv webbdesign’s utvecklings- och testmiljö i Firebug & Google Developer Tools
    1. Cloudbased Browser & Device- compatibility testing online
  5. CSS Media Queries & Responsiv webbdesigns-specifik kod
    1. Nödvändig Meta-kod för Responsiv Webbdesign
    2. CSS Media Query basics (grunder)
    3. Adaptiva och anpassningsbara måttenheter för responsiv typografi m.m.
    4. Manipulation av HTML dynamik via CSS (t ex. display: hidden vs. none)
    5. Adaptiva och responsiva bilder – på två sätt (utan JavaScript)
    6. Touch-baserade features för responsiva webbsidor
      1. Brist på indikations effekter jämfört med datorer (t ex. hover-effekt för länkar)
      2. Fingrar istället för datormöss och precisionsverktyg för klickande och val
      3. Handpositionering för smartphones och surfplattor
  6. Exempel Responsiv Webbdesigns kod- och Effekt i praktiken

Introduktion – Vad är Responsiv Webbdesign?

Responsiv webbdesign är ett populärt koncept för hur man kan bygga webbsidor idag. Detta då Responsiv webbdesign går ut på att anpassa en webbsida utefter vilka enheter som folk kan tänkas använda för att besöka webbsidan via. Om det så är Dator, Surfplatta eller Smartphone.

Med hjälp av Responsiv Webbdesign får man som utvecklare kontroll för att kunna anpassa en webbsida inför samtliga visningsscenarion som kan existera.

Tillvägagångssätt – Mobile-First vs. Mobile-Last

Inom Responsiv webbdesign finns där två olika ”kända” sätt för hur man kan gå tillväga för att bygga sina webbsidor som jag stött på.

Det ena är med den s.k. ”Mobile-First-approachen”, vilken brukar anses vara den bästa då detta tillvägagångssätt är ämnat för att inte bara optimera utseendet för webbsidor- utan även optimera dess laddningstid och prestanda.

Mobile-First möjliggör detta genom att man börjar med att designa hur webbsidan ska se ut för mobila enheter i t ex. porträttläge (för minsta viewport-bredden).

På detta vis får bara det allra väsentligaste plats på webbsidan, och allt annat som egentligen är ”överflödigt” för att förmedla webbsidans verkliga syfte hoppas över för att bespara kod, layout och flashiga funktioner, vilket då kan leda till optimerad laddningstid- vilket är desto bättre för mobila enheter då dessa kanske har sämre bandbredd jämfört med vad en dator med bredband hade haft. Och därefter är det sen då tänkt att webbsidan ”växer” efterhand som högre upplösningar besöker sidan.

Medan ”Mobile-Last-appraochen” gör motsatsen: då man börjar med att designa sidan för hur den hade sett ut i största möjliga ”viewport bredden” som man siktar in sig på att visa sidan för. Och därefter sen skalar ned sidan allteftersom ”viewport bredden” minskar- och anpassar layouten för de nya upplösningarna.

Mobile-Last kan därför även medföra sämre laddningshastigheter då det kan vara svårare att ”göra av med” saker från de större layouterna när man börjar närma sig de mindre- jämfört med att redan i början för Mobile-First haft begränsat sitt urval av sådana prestanda krävande delar då det första man designar för är just Mobila enheterna med sämre bandbredd.

Så Mobile-First vs. Mobile-Last är i grund och botten tankesätt som man utgår- och planerar från när man väljer att bygga sin Responsiva webbsida.

Mobile-Last kan även kännas lite ”enklare” i vissa fall när man är nybörjare och först börjar med Responsiv webbdesign- då detta är närmast hur man annars brukar bygga ”vanliga” webbsidor och designa deras layouter.

I denna guiden kommer jag demonstrera Mobile-Last-approach då detta är sättet jag själv personligen är mest bekväm med och skapat några responsiva sidor via tidigare. Men prova gärna på att Googla tips om hur man skapar Responsiva Webbsidor via Mobile-First och försök att lära er detta då det finns många fördelar med denna metod :)

Tekniker och kodningsmetoder – ”Enhetsspecifikt” vs. ”Breaking-points” (för & nackdelar)

När vi ska börja närma oss själva koden för Responsiva webbsidor så finns där olika metoder för hur man kan koda. Två metoder jag själv stött på är ”Enhetsspecifika kodningsmetoden” och ”Breaking-points kodningsmetoden”.

Det finns för- och nackdelar med båda metoderna, men den bästa av de båda enligt mig är Breaking-points kodningsmetoden. Vad är det då jag pratar om kanske ni undrar? Jo, dessa två olika metoder är vad vi kommer följa när det gäller på vilket sätt vi skalar om vår responsiva webbsida.

Breaking-points kodningsmetoden

Att tänka på

När det gäller breaking-points kodningsmetoden (hädanefter kan jag komma att kalla denne för BPK-metoden) så är det bättre om man kan göra den responsiva webbsidan stabil nog att endast behöva stora ändringar i layouten vid ett fåtal tillfällen typ en stor layout-förändring för surfplattor i porträttläge, en stor ändring för surfplattor i landskapsläge, en för smartphones i porträttläge samt landskapsläge. Varför det då? Jo, för att desto färre tillfällen som korrigeringar behöver göras- desto mindre Media Query regler behövs – desto snabbare laddningstid, samt desto ”smidigare” kommer webbsidan verka för dina besökare! Detta är dock inte alltid helt lätt att lyckas med, personligen anser jag det lite av en konst att lyckas med detta då jag själv upplevt hur tidskrävande/svårt detta ibland kan verka.

Nackdelar?

Det är tyvärr väldigt lätt i responsiv webbdesign att utgå från en ”inte så bra/genomtänkt” grund för webbsidan (speciellt som nybörjare). Detta kan då i BPK-metoden senare leda till att man blir tvungen att skapa massor med CSS Media Query regler tätt inpå närliggande upplösningar- när man egentligen vill försöka hålla sig till så få regler som möjligt för endast de större ändringstillfällena (surfplatta porträtt, surfplatta landskap, smartphone porträtt, smartphone landskap, etc.). Som nämndes i ovan område ”Att tänka på”.

Fördelar jämfört med Enhetsspecifika kodningsmetoden

Med BSK-metoden kommer vi alltid kunna behålla våra CSS Media Query koder oavsett vilka enheter som besöker vår responsiva webbsida då våra ändringar inte var baserade utefter specifika enheter- utan faktiska bristningspunkter i vår utgångslayout.

Hur kodningsmässigt?

För denne guides skull kommer jag bara att gå igenom hur man går tillväga när vi följer BPK-metoden. Denne går ut på att skala ned/upp (beroende på tillvägagångssätt) vår sida och identifiera när sidan ”går sönder”- med vilket jag menar när den börjar se annorlunda ut från hur vi vill att sidan skall visas. Och sedan då korrigera denna bristning så sidan ser bra ut igen för den nya upplösningen!

Så när detta inträffar identifierar vi de specifika måtten för när ”brytningen” skedde, och registrerar dessa i vår CSS Media Query kod som en regel för när ändringar i webbsidans layout skall ske- och inuti denna regel specificerar vi exakt vilka typer av ändringar som behöver genomföras/göras.

När vi använder oss av BPK-metoden så finns där en överhängande fråga om ”hur långt ska vi skala ned/upp sidan?”. För att besvara denna frågan så kan ni tänka er olika enheter ni vill nå ut till med er webbsida och tänka er vilka upplösningar dessa har- och sedan ha detta som ”max-upplösnings-gräns” och ”min-upplösnings-gräns”, eller så kan ni skala ned/upp sidan tills ni tror det inte är så stor mängd individer som kommer att kolla på sidan vid den upplösningen ni skalat om till (finns massor med statistik för detta (hur många som använder vilken typ av upplösning/enhet etc.) som enkelt brukar kunna hittas via Google eller andra sökmotorer på nätet).

Enhetsspecifika kodningsmetoden

Den Enhetsspecifika kodningsmetoden (hädanefter kan denne komma att hänvisas till som ESK-metoden) går ut på att man specificerar måtten för de specifika enheterna som finns idag som man vill sikta in- och optimera sin webbsidas layout för.

Nackdelar?

Uppenbara nackdelar med detta är bland annat att enheterna vi har tillgängliga att besöka internet och webbsidor via idag – ständigt förändras. Om vi då specificerar måtten för några specifika enheter som används idag, så lägger vi mycket tid på arbete som kan vara värdelöst om några månader, eller veckor om man verkligen har otur.

Fördelar?

En fördel med detta sätt är dock för t ex. Testningssyfte eller om ni har specifika besökare där ni vet vad de kommer att besöka er webbsida med – t ex. Alltid från en specifik iPhone modell, eller iPad osv. (hur ofta detta nu än må hända) Då kan det kanske spara tid att använda denne metod- eller även för att begränsa Media Query CSS koden som gör sidan responsiv- då denna kan göra att sidan blir aningen segare att ladda vid ”om-skalningen”.

Hur kodningsmässigt?

För vår Enhetsspecifika kodningsmetod så hade vår CSS Media Query kod haft en regel för en specifik enhets mått istället där sen då seriösa ändringar skulle ta plats för sidan.

Verklighetsbaserat exempel

Vid ett tillfälle valde jag för en av mina responsiva webbsidor att ha en maxgräns för 960px bredd, och mingräns för ca. 325px då det inte är många smartphones och mobiltelefoner som har den upplösningen i porträttläge idag (kollade upp detta med hjälp av statistik för vilka enheter och upplösningar folk använde vid det tillfället, som fanns insamlat och publicerat på nätet).

Responsiv webbdesign’s utvecklings- och testmiljö i Firebug & Google Developer Tools

När vi håller på att bygga vår responsiva webbsida så är det bra om vi har en ”testmiljö” där man enkelt kan skala upp och ned en webbsida och även identifiera när brytningar sker osv. Detta kan man enkelt och behändigt göra med hjälp av två av de populäraste webbläsarnas inbyggda webbutvecklings verktyg- Firefox Firebug, och Google Developer Tools för Google Chrome.

För att komma åt dessa lägen gör ni följande i Google Chrome: högerklicka på webbsidan ni önskar förhandsgranska med det responsiva designläget och välj ”inspektera” (chrome – [CTRL + SHIFT + I]). Därefter klickar ni på ikonen ni kan se nedan:

Toggle Device Mode aka Responsive testing environment

Som då kommer att öppna det Responsiva testläget för Google chrome som då ser ut såhär:

rwd mode gchrome

  1. Som ni då kan se i ovan bild så är det första inringade fältet i rött, möjligheten att välja specifika enheter vars upplösningar och skärmstorlekar då kommer läggas in för testning.
  2. Det andra rödmarkerade området är möjligheten att själva specificera specifika upplösningar att testa webbsidan i.
  3. Det tredje rödmarkerade området är en påminnelse om att sidan kan behöva uppdateras innan det responsiva testläget i Google Chrome fungerar optimalt.

Utöver ovan specificerade möjligheter och alternativ, så kan ni även se linjer som finns definierade både för höjd och bredd- personligen tycker jag detta är ett lite ”otydligt” sätt att visa vilken upplösning man skalat om webbsidan till, men det är i alla fall hur chrome gör saker och ting. För att förbättra detta kan man däremot ladda ned ett webbläsartillägg kallat ”Resize Window” för att (enligt mig) lättare kunna identifiera ”breaking-points” vid nedskalning av ens webbsida- dock funkar detta inte i chromes responsiva testläge, så detta behöver stängas först i sådana fall (vilket är lite trist).

Länk till var man kan ladda ned Resize Window webbläsartillägg för chrome, se nedan:
https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh

När vi pratar om Mozilla Firefox som webbläsare så har de sitt responsiva testläge placerat på annat ställe än tillsammans med inspektionsverktyget för webbsidor, istället hittar man deras responsiva testläge via webbläsarmenyn: Verktyg > Webbutvecklare > Responsiv designvy ([CTRL + SHIFT + M]). Se nedan:

firefox rwd mode

 

Personligen gillar jag Firefox Responsiva testläge så mycket bättre än Google Chrome’s, detta då man i Firefox responsiva testläge kan själv ”dra ut” en webbsida på bredden eller höjden som manuell omskalning på ett enklare sätt- däremot har Firefox responsiva testläge inte möjligheten som chrome’s testläge har att kunna välja specifika Enheter (såvitt jag kan se) att skala om sidan till att passa in för- om man skulle vara intresserad utav detta.

Cloudbased Browser & Device- compatibility testing online

Där finns även bra webbsidor för responsiva testanalyser av ens webbsida som kör en publicerad webbsida genom simulatorer för olika typer av enheter med deras specifika upplösningar och skärmstorlekar etc. Detta kallas även ibland för ”Live Cloudbased Browser Compatibility testing”.

Några sidor som erbjuder detta som ni kan testa och se vad ni tycker är som följer:

  1. https://www.browserstack.com/
  2. https://www.browserling.com/
  3. http://browsershots.org/

Där finns även en artikel om just sådan här typ av testning som kan vara av intresse att läsa igenom:
http://code.tutsplus.com/tutorials/browser-testing-in-the-cloud-redux–net-36521

Trots alla dessa sätt att testa sin responsiva webbsida finns där inget som slår den faktiska enheten man testar för tycker jag själv personligen. Exempel: testar ni er webbsida för iPad av någon speciell modell, så ta gärna och hitta någon som har en sådan iPad modell, och testa er webbsida hur den ser ut i denna modell så kan ni vara 100% säkra på hur den verkligen kommer se ut- för i vissa fall kan där finnas skillnader mellan simulerings- testsidorna och de verkliga enheterna.

Skillnader kan vara pixeldensitet eller finlir som bristande stödmjukvara för HTML5 Videotjänster och liknande. Ibland har inte dessa saker räknats med för de Cloudbaserade testing sidorna. Kan vara värt att ha i åtanke.

CSS Media Queries & Responsiv webbdesigns-specifik kod

Då har vi äntligen kommit till kodningsdelen för Responsiv webbdesign- och vi kommer att använda oss av en av de (enligt mig) bästa referenssidorna som stöd, nämligen Mozilla Developers Network Web Developers guide för CSS Media Queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries

I denna guide och på denna sida gås det igenom det mesta som har med Responsiv webbdesign att göra.

Nödvändig Meta-kod för Responsiv Webbdesign

För att indikera till mobila enheter att din webbsida är tänkt att vara responsiv och därför skalas om utefter CSS-koder så finns där en meta-tagg som informerar de mobila enheterna om detta. Den ser ut såhär:

<!-- Make browser understand this is responsive site and not in need of 'pinch-zoom-ins' -->
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

Se till att inkludera denna någonstans i ert <head> område för webbsidan.

CSS Media Query basics (grunder)

Media Queries CSS-kod i grund och botten är ganska simpla.

Man definierar en regel, och fyller sedan regeln med data- lite som i programmering när man sätter en IF-sats och definierar vad som skall hända inuti den.

Ett kodblock för Responsiv webbdesign kan se ut som följer:

@media (max-width: 960px) {
    div#mainContainer {
        width: 100%;
    }     
    /* added different values to match new responsiveness */
    article#mainContent { width: 100%; }
}

Man inleder alltid ett Media Query statement med @media. Därefter följer själva regel-definitionen skulle man kunna säga- i ovan fall så säger vi ”genomför dessa ändringar (inuti regeln) när bredden för sidan är mindre än- och upp till och med 960px”.

max-width attributet för vår Media Query ovan definierar när bredden för sidan är ”mindre än och upp till och med”.

Som ni sen kan läsa på MDN’s referenssida för CSS Media Queries så kan man definiera dessa för porträtt och landskapsläge, såväl som olika typer av media- t ex. om sidan skall bara anpassas för skärmar, eller även när den skrivs ut osv.

Man kan placera sin CSS Media Query kod i stort sett vartsomhelst- inkludera en separat fil som håller all sådan kod- eller lägga den längst ned i sitt vanliga CSS fil.

Testa er fram och försök på egen hand- tror ni kan lista ut det mesta själva – annars får ni mer praktiskt exempel på responsiv sida längre ned i denna artikel.

Läs igenom MDN artikeln- ni behöver inte gå igenom allting om ni inte vill- men kan välja ut de delarna som ni tycker verkar intressanta för just vad ni hade tänkt göra :)

Adaptiva och anpassningsbara måttenheter för responsiv typografi m.m.

Inom responsiv webbdesign kan det vara ganska attraktivt att ha textstorlekar som anpassar sig utefter att den s.k. ”viewport bredden” skalas ned eller upp för en webbsida. Där finns specifika CSS måttenheter för detta kallade ”vh” och ”vw” för viewport-height, och viewport-width.

Dessa måttenheter låter dig på din responsiva webbsida specificera måttenheter procentuellt baserade på sidans ”viewport height” respektive ”viewport width”.

Nedan kan ni läsa på mer om hur dessa måttenheter stöds i diverse olika webbläsare:

  1. http://www.quirksmode.org/css/units-values/viewport.html
  2. http://caniuse.com/#feat=viewport-units

Och här får ni även länk till en väldigt bra artikel hos CSS-tricks.com som går igenom dessa måttenheter i detalj om det är något ni skulle vara intresserade utav att använda:
https://css-tricks.com/viewport-sized-typography/

Sen är det upp till er själva att experimentera med dessa :)

Manipulation av HTML dynamik via CSS (t ex. display: hidden vs. none)

När det gäller att ta bort element eller bara gömma element på sin webbsida och man gärna vill undvika JavaScript och hålla sig till CSS- så är attributet ”display” väldigt användbart.

Där finns två attributvärden som kan göra jobbet för en här:

  • none
  • hidden

display: none; kommer att fysiskt sett ”ta bort” ett element från webbsidan- och därmed ändra hela dynamiken av sidan, medan display: hidden; enbart kommer att ”gömma” elementet från besökares ögon- men fortfarande ha kvar elementet på sidan och därmed även bevara dynamiken för sidan.

Detta är användbara tips och tricks att tänka när det gäller layouten och hur den påverkas vid manipulation på sådant vis av HTML-innehållet via CSS.

Adaptiva och responsiva bilder – på två sätt (utan JavaScript)

När det gäller att anpassa sina bilder utefter upplösning på responsiva webbsidor så finns där säkert många sätt- varav några är JavaScript bibliotek som kan dynamiskt anpassa bilderna utan att man själv som utvecklare behöver bry sig speciellt mycket- dock är detta JavaScript och inte alltid så populärt + att det är lite mer krävande att ladda in än vad HTML och CSS är.

Via HTML och CSS kan man dock anpassa bilderna antingen genom att ange bredd och höjd med procentuella måttenheter (via CSS- då jag tvivlar på att detta funkar i HTML- men ni kan ju alltid testa bara för sakens skull), och sedan är det andra sättet att använda CSS Media Queries för att specificera att ”vid den specifika bredden/höjden skall bilden ändras si och så”.

Då kan ni även använda pixlar som måttenhet.

Touch-baserade features för responsiva webbsidor

Brist på indikations effekter jämfört med datorer (t ex. hover-effekt för länkar)

När man designar webbsidor för Touch-baserade enheter finns där några saker att tänka på. T ex. att touch-baserade enheter inte har den här s.k. ”link-hover” effekten som datorer med datormöss har som träder i kraft när man håller musen över en länk.

Man kan då istället använda sig av de äldsta tricken i boken när det gäller indikationer för klickbarhet så är de flesta vana vid att klickbara saker på webbsidor är understrukna då detta brukade vara en standard förr som många fortfarande håller fast vid.

Så understruken text kan kanske kompensera för bristen av ”hover-effekt” och liknande för länkar.

Fingrar istället för datormöss och precisionsverktyg för klickande och val

Touch-baserade enheter har heller inte lika lätt för att klicka på mindre ”klickområde” som en dator mus kanske inte har några problem att komma åt- då man använder fingrarna istället för ett precisionsverktyg att klicka med (undantaget de som klickar med touchpennor eventuellt).

Detta innebär att man måste tänka på sådana här saker när man designar sina layouter för touch enheter- desto större klickområde- desto bättre, och desto lättare för besökare att klicka på saker på ens webbsida.

Handpositionering för smartphones och surfplattor

Ytterligare en aspekt att tänka på (nu går vi in lite på ett område kallat Interaktionsdesign) är hur folk kan tänkas hålla t ex. mobiltelefoner av olika storlekar, eller surfplattor när de är ute på internet. Detta kan ha stor effekt på hur ni bör designa responsiva webbsidor när ni börjar närma er upplösningar motsvarande de av surfplattor och smartphones.

Exempel Responsiv Webbdesigns kod- och Effekt i praktiken

div.box {background-color: #ccc; width: 800px; border: 1px solid #000; padding: 6px 12px; box-sizing: border-box;}
div.box p {font-size: 36px; color: #00f; line-height: 1.5em;}

@media (max-width: 800px) {
    div.box {
         background-color: #0f0;
          width: 600px;
    }
    div.box p {
         font-size: 28px;
          color: #000;
    }
}

@media (max-width: 600px) {
    div.box {
          background-color: #00f;
          width: 400px;
    }
    div.box p {
         font-size: 18px;
          color: #fff;
    }
}

@media (max-width: 400px) {
    div.box {
         background-color: #000;
          width: 200px;
    }
    div.box p {
         font-size: 14px;
          color: #0f0;
    }
}

test1

test2

test3

Vid frågor om hjälp eller bara allmänt- se e-post på kontaktsidan.

Detta inlägget skriver jag i syfte om att informera er läsare som sysslar med- och är intresserade utav webbdesign/webbutveckling eller kanske bara datorer och internet i allmänhet och någon gång stött på länkadresser i något sammanhang.

För många som använder internet idag så känner de säkert igen länkar / URL:er som ser ut som t ex: http://www.domain.se , eller www.domain.se eller domain.se .

Alla ovan är giltiga länkar som tar med olika delar, för webbutvecklingssyfte brukar man använda sig av 2 typer av navigerings-länkadresser när man hänvisar till material som skall användas på sidan, eller hämtas in från utomstående källor: Globala/Absoluta resp. Lokala adresser.

Absoluta/Globala länkadresser

Den första är den absoluta/globala länkadressen, som inkluderar http://www , vilket är den del av en länkadress som indikerar bl. a. vilket protokoll som används för kommunikationen webbläsaren hanterar. Protokoll är utanför det jag tänkt gå igenom, men kan åtminstone nämna att http är HyperText Transfer Protocol. Och som jag nämnt vid ett tidigare tillfälle är i stort sett ”hypertext” = webbinnehåll. Vilket då gör att protokollet på svenska skulle kunna kallas webbinnehålls överförings protokoll.

Som ni säkert också noterat så är absoluta/globala länkadresser ofta inkluderande domännamnet för själva webbsidan som länken leder till.. Exempel: www.domain.se

Hur som helst, det var en typ av adresser som används, och den brukar användas speciellt om man hänvisar till innehåll från externa, eller utomstående källor annat än ens egna webbsida.

ATT OBSERVERA! När dessa länkadresser används så hänvisar ni till någon annans webbserver/webbhotell, vilket innebär att ni ”lånar/snor” deras resurser för att kunna ladda det externa innehållet till er webbplats – i vissa fall anses detta som okej, i andra, inte lika okej.. Det är upp till er även här att ha koll på när det är lämpligt att använda sådana adresser, speciellt om ni gör webbprojekt åt kunder, då kan det vara extra viktigt(!).

Lokala länkadresser

Lokala länkadresser är den andra typen av länkadress som är populär att använda sig utav när man pysslar med webbutveckling. Lokala länkadresser utgår från själva källkods/webbdokuments-filen som skall hänvisa till innehåll via länkadress. Som exempel för detta kan ni föreställa er att vi har vår index.html webbdokuments fil som har en <img> tagg källa (src) som skall peka på en bild i en undermapp som vi har på vår webbserver eller webbhotells domän inuti en undermapp.

För att lättare förstå Lokala länkadresser kan det vara behjälpligt att se hierarkin framför sig, därför har jag tagit en screenshot av en exempel-hierarki som ni kan jämföra med och se hur jag menar, se nedan:

mapphierarki exempel vid webbutveckling

Mapp-hierarki för webbutvecklings projekt

Som ni då kan se i ovan bild så har vi index.html i den s.k. ”rotmappen” – högsta hierarkiska lagret i projektmappen, och sedan har vi en bild: fruit.png inuti mappen bilder.

Med detta vill jag då visa och jämföra att en Lokal länkadress hade bara sett ut som följer: bilder/fruit.png då den utgår från källkodsfilen som skall hänvisa till bilden och navigerar inuti egna webbservern skulle man kunna säga. http://www. har man inte med som ni ser, och inte heller själva domännamnet i fråga för webbsidan. För lokala länkar är allt som behövs navigering utifrån filen man länkar från inuti ens egna server/domän.

Globala/absoluta länkar vs. lokala länkar

Global/absolut länk:
http://www.domain.se/bilder/fruit.png

Lokal länk:
bilder/fruit.png

Om din webbsida finns på www.domain.se räcker det att ni använder er av lokala länkar, medan om www.domain.se inte är er domän, så bör ni använda globala/absoluta länkar (antaget att ni tänkt igenom just ert scenario och övervägt tillåtelse för användning, etc.).

Länkmekanik – Navigeringskommandon och funktion

Både Lokala såväl som Globala länkar har gemensamma möjligheter att navigera sig fram till olika filer och undermappar, detta tack vare båda typerna av länkar hänvisar till webbservrar, vare sig det är ens egen, en hyrd, eller någon annans.

Ni kan föreställa er länkmekanik som det sättet ni själva använder när ni navigerar er bland era egna mappar på er egna dator – fast istället för att göra det med muspekaren, så kommer vi använda kommandon i textform – typ såsom man kan göra via konsollfönster/CMD i Windows.

Gå in i undermappar

För att gå in i undermappar från en nivå ovanför den undermappen, så kan man använda mappnamnet + snedstreck (/) som t ex. ger: bilder/ för att gå in i bilder-undermappen som ni ser på screenshotten av en exempel hierarki ovan.

För att gå in i först en undermapp, och därefter ytterligare en undermapp inuti den första undermappen man gick in i, upprepar man bara samma kommando som då kan se ut såhär exempelvis: 1:a undermappnamnet + snedstreck (/) + 2:a undermappnamn + snedstreck (/), vilket då kan resultera i: bilder/slideshow/ <- om vi antar att vi hade haft en undermapp vid namn slideshow inuti bilder.

För att komma åt filer i undermappar

Så skriver ni filnamn + filtyp direkt efter snedstrecket (/) som tog er in i en undermapp där filen ni är ute efter befinner sig.

Exempel: bilder/fruit.png

För att komma åt fruit.png inuti bilder-undermappen.

Backa ur en undermapp

För att ”backa ur” en undermapp så använder man ett kommando bestående utav 2 st. punkter (.) + ett snedstreck (/), ser ut som följer: ../

Så om ni föreställer er att vi har gått in i undermappen bilder i ovan exempel, och vill ta oss tillbaka till rotmappen, så skriver vi: bilder/../  <- vilket i det här fallet är samma sak som +/- 0, med andra ord, ganska meningslöst.

När är detta användbart då om det i stort sett är meningslöst för ovan demonstrerade scenario? Jo, om ni tänker er att vi vill länka till en bild från vår styles.css stilmalls fil som ligger inuti undermappen css så måste vi först ta oss ur css-undermappen för att sen kunna gå in i bilder-undermappen för att komma åt bilden vi vill hänvisa till.

Exempel på detta (tänk er att vi länkar från styles.css): ../bilder/fruit.png <- ger oss en utmärkt lokal länkadress för att kunna komma åt bilden fruit.png från vår styles.css stilmalls fil.

1) ../           först tar vi oss ur css-undermappen.
2) bilder/       sen går vi in i bilder-undermappen.
3) fruit.png     slutligen kommer vi åt fruit.png bilden i bilder-undermappen.

Du har säkert blivit förbryllad av hur de hexadecimala färgkoderna inom webbdesign och webbutveckling fungerar och det tänkte jag förklara i detta inlägget.

Hexadecimala färger är egentligen ganska enkla när man väl förstått grundkoncepten som bygger upp dem.

Ett av dessa grundkonceptet är att de hexadecimala färgerna bygger på färgprincipen RGB. Vilket innebär att man anger ett typ av ”del-värde” som kan liknas vid en procentuell intensitet för varje färgpott som är:

  • R = Röd
  • G = Grön
  • B = Blå

Mer i detalj så står ”hexa” för ett talsystem där basen är 16. Vad vi menar med detta är att talsystemet som används för hexadecimala färgkoder skiljer sig från det vi är vana vid (det decimala talsystemet där basen är 10) och likaså talsystem såsom det binära där basen är 2.

För dig som inte är så bekant med hur talsystem fungerar så kan du se nedan en detaljerad genomgång och förklaring:

Matematiska Talsystem förklarat ytterligare för ökad förståelse

I ett talsystem så har vi ”x” antal siffror som utgör valfritt tal.

T ex. 5 siffror i följande följd: 12500 utgör talet tolv tusen fem hundra i vårt decimala talsystem.

Man kan se dessa siffervärden gå från höger till vänster.

Där talet längst till höger också kan skrivas upphöjt med 0 (^0), där sedan för varje siffra man rör sid i sidled åt vänster så ökar exponenten (upphöjt-med-talet) med +1 (^0+1 t ex. för nästa siffra till vänster om siffran längst till höger).

Det är detta som avgör olika siffrors ”värde” och betydelse som sen i sin tur utgör ett visst tal.

Ta till exempel det decimala talet 11. Eftersom talsystemet är av typen ”decimal” så har vi basen 10.

Om vi då följer ovan logik med att siffran längst till höger ->, är upphöjd med 0 (^0)- då får 1:an längst till höger i talet 11 värdet 1*10^0.

För dig som inte kommit hit i matematiken ännu så funkar det som så att om ett tal är upphöjt med 0, oavsett vilket tal det är, så får vi värdet 1.

Så 10^0 = 1, precis som 12345^0 = 1.

Vi tog 1* 10^0 då vårt mest högra värde i talet 11 var 1. Hade vi haft talet 12 hade vi tagit 2 * 10^0 istället och då fått talvärdet 2, då uträkningen för 10^0 fortfarande blir 1 och vi då får 2*1=2.

Nu när vi har lite koll på hur talsystem generellt fungerar, så kan vi ta en närmare titt på vad som händer när vår bas för talsystemet förändras.

Hittills har vi enbart kollat på talsystem av den decimala typen där basen är 10, det talsystem vi använder till vardags och är vana vid.

Men inom datatekniken t ex. då pratar vi om bitar, som är baserade på det ”binära” talsystemet, där basen istället är 2.

För våra hexadecimala färger, använder vi oss istället av ett talsystem där basen är 16, därav ”hexa”.

Summerat kan vi säga att:

Basen upphöjs med ett steg för varje bit/siffra som representerar vårt tal från höger (->) till vänster (<-).

För att förtydliga detta ytterligare kan vi visa det med ett enkelt binärt exempel  (då detta är lätt att räkna med)4 bitar som ser ut som följer:
0    0    0    0 <- Där värdena för vardera bit är som följer:
23 22   21   20

Som då motsvarar:

8   4   2   1    <- uträknat.

I det decimala så fick vi i grundskolan lära oss att första talet längst till höger var s.k. ”ental” men de gav oss aldrig den bakomliggande (lite mer avancerade) matematiska anledningen, det är den vi har lärt oss nu.

Så nu vet vi att detta helt enkelt var för att vårt talsystem har basen 10 och talet längst till höger alltid får upphöjt med 0, medan efterföljande tal åt vänster ökas exponenten med +1 alltså blir nästa tal 100+1

osv. :)

Visst är matematik roligt när man väl förstår det och får förklaringar bakom saker man använt hela sitt liv utan att ha en ”riktig” bakomliggande förklaring för varför det var så? :P

Hursomhelst, nu borde du förstå hexadecimala färgvärden bättre, testa gärna själv och återkom gärna om du skulle ha frågor ^^


Och eftersom vi kan ange varje s.k. ”färgpott” med 2 bitar(se #RRGGBB <- två färgvärde för var färgpott) innebär detta att vi använder oss av ett fullt färgpotts-värde på 16^2.

Detta då ^2 motsvarar våra 2 bitar, 16 då varje bit har basen 16 i ett hexadecimalt talsystem, 16^2 ger oss 256 möjliga värden på 2 bitars lagringskapacitet med hexadecimala värde.

Och eftersom man i datatekniken alltid räknar med/inklusive 0:an (såvida inget annat specificerats)kommer vi att kunna ange värden från 0-255 – då detta inkluderar nollan och resulterar i 256 värden!

Så nu när vi har det konceptet klart för oss är det dags att gå vidare.

Alla möjliga hexadecimala färgpotts-värden presenterade

Varje färgpott består alltså av 2 bitar i hexadecimala värden/2 hexadecimala värden, och då bör vi kolla på hur hexadecimala värden av olika typer skrivs och vad dessa representationer motsvarar och innebär, se nedan:

Hexadecimala värde Decimala värde
1 = 1
2 = 2
3 = 3
4 = 4
5 = 5
6 = 6
7 = 7
8 = 8
9 = 9

Sen kommer vi till den intressanta delen – eftersom vi bara kan representera 1 värde för varje 1 bit, så kommer talet och värdet 10 för varje bit att orsaka problem för oss, då detta i det decimala talsystemet tar upp 2 värden/2 tal/2 bitar.

Som det då funkar i hexadecimalt talsystem, då vi måste fortsätta upp till 16 värden per bit/per värde, så kommer talen från 10-15 att representeras av bokstäver istället! (Notera att jag säger upp till 15 som maxvärde då man alltid räknar med nollan! kan ses ovan).

Se nedan lista av resterande hexadecimala värde från 10 upp till och med 15:

Hexadecimala värde Decimala värde
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15

Som du nu säkert kan förstå om du någon gång experimenterat lite själv med hexadecimala färger så kan du se att bokstaven F kan tolkas som ”fullvärde”.

Detta då F är det högsta värdet varje bit kan ha i en färgpott.

Har vi då 2x F så borde detta då alltså innebära absolut fullt värde för hela färgpotten, alltså 255 i vårt decimala talsystem då vi får 16^2.

16^2  blir 256, men i och med att vi räknar med 0:an så får vi 255 för våra 2 värden/bitar med vardera hexadecimalt tal!

Och då förstår du säkert också att 2 st. 0:or motsvarar en ”tom” färgpott som då borde leda till ”avsaknad av färg för den färgpotten”.

Bra liknelser för att hjälpa med förståelsen för RGB-färger hämtat från fysiken och vardagen

Ljus i fysiken hjälper oss förstå vit färg i webbdesign och webbutveckling

En grymt bra liknelse från fysiken som förklarar väldigt bra hur RGB fungerar, är liknelsen för hur Ljus är uppbyggt och hänger ihop om man studerar det närmare.

Ett bra praktiskt exempel som visar på liknelsen är när man tar den ”vita” färgen från vilken lampa som helst, och belyser denne genom ett spektrum, så kommer man kunna se på andra sidan av spektrumet hur ljuset har delats upp i dess olika våglängder.

Detta visar klockrent hur alla färgerna (i webbdev sammanhang färgpotterna) bidrar till att skapa vitt ljus (vit färg i webbdev sammanhang).

För det är ju samma som gäller för webbdesign och webbutveckling där då fulla färgpotterna för alla färgpotter som finnsRöd, Grön såväl som Blå, krävs för att skapa vit färg!

T ex. om man vill ha vit textfärg blir hexadecimala färgkoden: #FFFFFF.

Svarta kläders ljusabsorption – ett vardagsexempel som hjälper förklaring av svart färg i RGB för webbdesign

På samma fysiklektion som läraren delade insikter som gav ovan förståelse för det vita ljuset, så nämnde läraren även att det vi upplever som ”svart färg” egentligen är avsaknad av färg.

Och att detta är orsaken till att svarta kläder blir varma på sommaren när solen är framme.

Detta då den svarta färgen egentligen som sagt är avsaknad av färg/våglängder (för ljus), vilket gör att den absorberar alla färger (våglängder) som solen förser den med för att försöka kompensera för dess avsaknad av färg.

Vilket i sin tur då bildar värmen vi upplever under sommarens soliga dagar :)

Detta är också varför man är som svalast i vita kläder på sommaren.

Av samma anledning som för svart färgs avsaknad av våglängder/färger så för vit färg gäller istället motsatsen.

Att vit färg redan innehåller fulla spektrumet av färger så därför stöter den vita färgen bort alla våglängder istället för den är redan ”mättad” (skulle man kunna säga) av våglängder.

Sammanfattat så kan man se att vit färg reflekterar/stöter bort allt ljus, då det redan är mättat, och tar därmed inte heller upp någon värmeenergi i solen.

Medan det svarta saknar färg och därför gärna suger åt sig solljusets våglängder och därmed absorberar värmeenergi.

Primära färgerna som utgör våra hexadecimala färgkoder

När det gäller våra primära färger:

  • Rött
  • Grönt
  • Blått

Som RGB metoden representerar så kan vi då säkert också förstå att #FF0000 resulterar i en Röd färgvi fyller Enbart* den röda färgpotten.

Medan istället #00FF00 resulterar i en Grön färg då vi fyller den färgpotten till fullo.

Och slutligen då #0000FF ger oss en Blå färg då denna färgpott är fylld till fullo.

Alternativa färggivningsmetoder i webbdesign och webbutveckling

Det var ju ganska enkelt!

Dock så blir det lite mer komplicerat när vi ska försöka skapa t ex. ”hälften så full färgpott” i hexadecimala tal, etc.

För då man måste räkna på detta – såvida man inte använder den lite mer ”raka” formen för färggivning i CSS: rgb(0,0,0) eller rgba(0,0,0,0);

Se CanIUse.com för Webbläsarstöd för RGB() och RGBA() funktionerna i CSS(3).

rgb(0,0,0) är en färggivningsmetod i CSS som låter dig ange de decimala talen för färgpotterna istället för hexadecimalt – alltså från 0-255 färgvärde för varje färgpott.

rgba(0,0,0,0) är en annan färggivningsmetod i CSS3 som låter dig ange även en alpha-kanal för transparens/genomskinlighet (sista värdet i parentesen).

Genomgång av Hex-Dec värdekonvertering för att få förståelse för ”hur fulla” de olika färgpotterna verkligen är

Sådär ja, då vet vi vad alla möjliga bokstavs- och sifferkombinationer motsvarar.

Vi har även lite ”lättsmälta” liknelser för att komma ihåg hur och varför svart, vitt såväl som de primära (röd, grön, blå) färgerna skapas/genereras/byggs upp.

Börja smått – Dela upp hexadecimala färgkoden i dess 3 beståndsdelar Röd, Grön och Blå

För detta exemplets skull ska vi använda oss utav färgkoden #2D9FF0 (notera att hexadecimala färgkoder kan skrivas både med stora såväl som små bokstäver (versaler/gemener) väl i koden – själv föredrar jag att skriva med små bokstäver, men valt att skriva med stora bokstäver för tydlighetens skull i detta inlägget).

Om vi ska dela upp #2D9FF0 i dess tre beståndsdelar får vi som följer:

2D = Röd färgpott
9F = Grön färgpott
F0 = Blå färgpott

Nästa steg – Räkna ut färgpotterna var för sig- Från hexadecimala till decimala värden

Vi börjar med den första färgpotten (röd):
2 är första biten i färgpotten, och D är den andra och sista biten i färgpotten.

Den första biten (längst till vänster) i en färgpott multipliceras med 16 när man ska räkna ut det decimala värdet, och då kanske du undrar varför detta är?

Se bild nedan som visar varför:

Hexadecimal till decimal bitvärdes konvertering

Hexadecimal till decimal bitvärdes konvertering

Som du då kan se ovan så är hexadecimal -> decimal värdekonvertering ganska straight-forward :)

Hexadecimal kortform förklarad

Men innan detta inlägget är över ska jag också bara som hastigast nämna att hexadecimala färgkoder kan skrivas på en s.k. ”kortform” där man bara använder 1 bit per färgpott istället för 2.

Detta går dock Endast* att göra om båda färgpottens värden är Identiska* t ex:

Har vi den full-röda färgen: #FF0000 <- så är färgpottens värden identiska – F & F – och kan därför även skrivas som #F00 <- som du säkert noterar är även Gröna och Blåa färgpotternas värden identiska och kan även dessa därför förkortas till 1 bits hexadecimalt färgvärde ;) Som jag gjorde direkt i ovan exempel.

Hoppas du känner att du har fått bättre förståelse för hur saker och ting ligger till och fungerar, samt varför och att du har nytta av kunskaperna du nyss lärt dig.

Tills nästa gång :)