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:

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:

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

test1

test2

test3

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

Step 1: File structure

MainFolder
-file:   index.php
-file:   index.html (base-template file)
-folder: incl/
-file:   incl/header.php
-file:   incl/footer.php
-file:   incl/config.php
-file:   incl/functions.php
-folder: css/
-file:   css/mainstyles.css
-folder: img/


Step 2: Create the base-template file (index.html)

This is where we build our website as a normal .html file with headers, body, footer, and the whole layout in one file.
This will in turn be our base template to later disect into 3 pieces (header.php for header code, index.php for body and site code, footer.php for endpage-code)

Our base-template file will be very basic and simple and can be seen below:

Step 3: Breaking this down for ya in detail how this is going to work.

Okay, so the idea is to divide this website we just created into different parts (header, content and footer)- and we do this by analyzing which parts will be recurring throughout every single subpage of the website.
For example we can be pretty sure that all the code belonging to the “header” section including the main menu will be available on every single subpage- as will the footer code. This means that we can take all this code and place it in separate files – in our case we call these files header.php & footer.php and have them placed in a folder named: incl, which stands for “includes”.

Why do we do this then? Well the idea is to later include these separated external files which together contains all the code for the entire page layout.
In this way we “re-create” the website section by section by including these parts into the “main-subpage-file” – such as index.php for the mainpage, and contact.php for the contact page for example, etc.

Step 4: Start disecting & dividing the individual sections of the page which will reoccurr throughout all subpages of the website.

Now as you can probably see we included the “<article>” in the header.php file, while we included the “</article>” in the footer.php file, but totally ignored the content of <article> in both files.
We did this because we plan ahead- every subpage will probably have the need for an general “content-container” to place that particular pages contents in – so we make the <article> container itself become re-occurring, whilst the content of the container- is not.

So perhaps you’re asking yourselves now whats next? Well, we need to put the website back together again after having disected it- thats our next move- including the header.php & footer.php in the index.php for the main-subpage.

Now the website will have been recreated in index.php since it first includes header.php (and all the code this file holds), then the HTML-content for that specific subpage, and last but not least- the footer.php file and the code that file holds.

Step 5: Explain the overflow files such as config.php & functions.php (plan ahead purpose)

Okay, so you might be wondering now that we seem to be done already why I made 2 extra files in the incl/ folder? Well this is simply because “looking & planning ahead” – in the future the config.php file will hold configuration code for the entire page, while the functions.php file will hold useful functions which later can be included into the header.php to be available for all of the respective subpages.

And another thing worth pointing out- the footer.php will be able to hold all the JavaScript file inclusions as well as Google Analytics code which you want to load in at the end of all subpages. Which also is a very nifty, useful and handy feature to have available.

Step 6: Spice up the webpage a bit more with dynamic SEO content for each individual page? as well as Titletext? 🙂

There are tons of fun stuff you can do with a Dynamic website template like this in PHP – for example if we want unique <title> texts for each individual subpage – we only replace our current HTML content in the header.php file
within <title> & </title> with something like: <?php echo $subPageTitleVariable; ?>
And then all left to do is to in index.php ABOVE WHERE WE INCLUDE HEADER.PHP -> place $subPageTitleVariable = "our specific subpage &lt;title&gt; text"; for example. and this would be available for the header.php file to make use of seeing as how we placed it ABOVE where header.php was included and PHP works vertically through the code from top->bottom. with top-content being available for bottom-content on a code page.

This method & technique can also be utilized- and comes in very handy for On-Page SEO where you need to specify specific keywords/descriptions for each individual subpage.

As a Last thing to mention I will recommended you to start the config.php file by placing <?php error_reporting(-1); ?> to report ALL Possible (PHP) errors on the page for debugging (recommended to be turned off when publish page – 0 as value instead of -1). And Also to include config.php ABOVE HEADER.PHP in INDEX.PHP file. so that the Error Reporting is active for ENTIRE PAGE.

Good Luck with all your Coding out there now 😉
This tutorial was brought to you by: https://www.webbdev-essentials.net

Hope you learn something new and get some new ideas for your next projects 😉 Was a pleasure helping out and hopefully inspiring to new creativity 🙂 Enjoy!

Ett litet snabbt “nattinlägg” där jag tänkte ta upp lite tips och tankesätt för hur man kan strukturera upp sina webbprojekt i mån av filer och organisering med hjälp av mappar, såväl som hur man namnger respektive för att funka så bra som möjligt på nätet.

Saker att undvika för namngivning av mappar och filer avsedda för webben

Ni bör nog undvika att döpa era mappar och filer för webbsidor som skall användas/skapas för publicering med följande:

  • Undvik Svenska tecken – undvik detta då internet är internationellt, oavsett vad du har för domän, etc. Och dessutom så är operativsystemen som hanterar mapparna och filerna (webbservrarna) bättre lämpade att hantera engelska alfabetet för mappnamn och filnamn.
  • Inga mellanslag eller specialtecken i mapp/filnamnen – mellanslag är ett typ av “specialtecken” och kommer därför i webbläsarens URL att översättas till typ %20 istället för ditt mellanrum(!). Vilket innebär att en fil du har döpt till t ex: min indexsida.html, kommer att omvandlas till: min%20indexsida.html <- vilket inte är så roligt kanske. Väldigt enkelt att undvika dessa scenario dock genom att helt enkelt bara skippa mellanrum och specialtecken i ens fil- och mapp-namn.
    Smart kan vara att hålla sig till engelska alfabetet – siffror är dock också OK 🙂 Har man filnamn som består av flera ord för att vara beskrivande (vilket är bra praktik att följa), så kan man använda bindestreck istället för mellanrum och understreck istället mellan orden i filnamnet.
  • Undvik att blanda gemener och versaler- använd endast små bokstäver, detta är mycket för er egen skull, då detta kan göra utvecklingsprocessen enklare på många fronter. Det blir helt enkelt enklare om man håller sig till endast små bokstäver (brukar jag själv numera alltid göra då jag haft dålig erfarenhet av att döpa filer och mappar med stora första bokstäver etc. i början av min tid som webbdesigner/webbutvecklare). Detta är speciellt viktigt(!) för bildfiler då dessa behandlas som case-sensitive. Webbdokuments filer kan vara case-sensitive precis som bilderna, lite beroende på operativsystemet av webbservern man använder för att publicera sin webbsida.
    Case-sensitive för er som ännu inte är bekanta med vad detta innebär är att stora bokstäver är inte samma bokstäver som små.

Hittade en väldigt trevlig och bra sida som verkar ha bra koll på vad som gäller för namngivning av filer, besök den gärna för att få bättre koll på vad som fungerar bäst för namngivning av filer avsedda att publiceras på webben! Se länk nedan:

http://www.motive.co.nz/guides/design/naming-folders-and-files.php

En annan PDF som sammanfattar och ger en god översikt av det väsentligaste för namngivning av mappar och filer samt lite praktiska exempel på hur olika giltiga namngivningar hade kunnat se finns på följande sida:
https://www.it.umass.edu/sites/oit.umass.edu/files/2011/06/30/naming.pdf

Översikts och referenssida för URL-encoding och varför det kan vara användbart!

För att se hur olika specialtecken blir översatta i URL:er kan ni se följande sida: W3Schools URL-Encoding referenssida.

På den sidan kan ni se samtliga specialtecken och hur de blir översatta i webbläsaren, detta är bra att känna till också, då det fortfarande finns utvecklare som faktiskt använder specialtecken i sina filnamn eller URL:er för webbsidor – då kan ovan länkade referenssida hjälpa er att avkoda/tolka vad URL:en egentligen är.

URL:er som har speciella tecken behöver inte enbart vara p.g.a. att utvecklaren döpt sina webbprojekts filer med specialtecken, utan kan också vara p.g.a. URL:er som PHP/JS Script för sidan har genererat och ibland bildas där specialtecken i URL:en i sådana fall.

Tips på hur man kan tänka vid organisering av sitt webbprojekts filer med mappar

Själv brukar jag organisera CSS-filerna till en undermapp, bilder till en undermapp, JavaScript-filer till en undermapp, Material/anteckningar som t ex. “todos”/dokumentation brukar jag placera i en undermapp.

Sedan i sidans rotmapp (antaget att webbplatsen inte har många underssidor), brukar jag placera samtliga undersidors webbdokuments filer. Typ index.htmlundersida1.htmlundersida2.html, osv.

I inlägget för Globala och Lokala länkadresser/URL paths finns där en printscreen där ni kan se ett exempel på mappstruktur för ett webbprojekt.

Sökmotoroptimerings aspekt att tänka på för mapp namngivning

Länkadresserna som kommer att finnas på din webbsida när den blivit publicerad, tar oftast och utgår från din domän, t ex. www.domain.se, fast för att sedan komma åt t ex. undersidor på din webbplats, så kan länken bli antingen www.domain.se/subpage1.html, eller: www.domain.se/subpage.

Vilket man väljer kan bero på hur man vill sökmotoroptimera sin sida, om det räcker med en enstaka webb fil för undersidan, hur ens egen preferens är, såväl som storleken för webbplatsen (antalet undersidor).

Det andra alternativet: www.domain.se/subpage, går att ha om man har en mapp i domänens rotmapp som heter: subpage, varav inuti denne mapp det finns en index.html fil. Detta är bra att lägga på minnet för att kunna göra sökmotorvänliga länkarURL-pathen till webbsidor väger väldigt mycket sökmotoroptimeringsmässigt. Det är betydligt bättre med länkar som människor kan förstå än länkar som t ex: www.domain.se/?q=asd123&w=300&h=250 (liknande länkar kan skapas via t ex. PHP).

index.html som ligger i en mapp anges för “standardsidan” för den mappen, detta innebär också att detta är den webbdokuments fil som öppnas som standard utan att behöva skrivas ut i URL:en – därav: www.domain.se/subpage, och inte: www.domain.se/subpage/index.html. Dock bör ni också veta att båda dessa sätten uppvisade här innan fungerar för att besöka index.html filen i mappen subpage.

I webbutveckling har vi en hel del typsnitt vi kan använda för att få just den typen av utseende vi är intresserade utav att ha på vår egna webbsida.

Men det är mycket tankar som bör övervägas innan man bara klistrar på ett typsnitt på sin webbsidas texter och innehåll – detta då bl. a. läsning av material och texter på bildskärmar skiljer sig från läsning av material och texter på papper. Anledningar och faktorer som bidrar till detta förklaras nedan.

Tre typer av populära typsnitt som brukar användas och varför just dem är utvalda

Några av valen som finns tillgängliga är Serifferade typsnitt (serif), sans-serifferade typsnitt (sans-serif), monospace:ade typsnitt, såväl som några andra som jag inte tänker ta upp och gå igenom i det här inlägget.

Dessa tre typsnitt jag nämnde ovan är nog dock tre av de viktigaste och mest använda typsnitten vi har (iaf. för oss som bloggar på webben inom kodning då monospace är ganska populärt för kodexempel – såväl som för folk både involverade i text för webb såväl som för tryck (webb = sans-serif, tryck = serif).

Serifferade vs. sans-serifferade typsnitt, och vilket som används bäst var

Serifferade typsnitt ter sig som så att bokstävernas ändar har en liten “kant”-liknande dekorativa utskott. Dessa är till för att vägleda vandrande ögon för läsning på t ex. papper där ögonen tar hjälp av serifferna för att gå vidare till nästa ord i texten snabbare än vad de annars hade kunnat. Detta är dock endast optimalt på papper, då serifferade typsnitt på webbsidor riskerar att “kladda” serifferna om man läser texten med låg skärmupplösning, vilket då istället stjälper och kan sakta ned läshastigheten jämfört med effekten seriffer hade för läshastighet på papper.

Sans-serif (från gammalfranskans “sans” som betydde: utan/avsaknad av- (som i sin tur härstammar från latinens “sine” som i sin tur betydde: utan) se wikipedia för mer detaljer) å andra sidan saknar sådana pappers läs-underlättande “kanter” och satsar istället på jämna och stabila bokstäver utan mindre bihang som riskerar att kladda och förvirra ögonen på bildskärmar!

Anledningen att serifferade typsnitt riskerar att kladdas ut på just bildskärmar och inte papper, är då upplösningen för bildskärmar består av pixlar, som i stort sett är pyttesmå kvadrater som utgör rutnätet där varje ruta tilldelas en specifik färg och ljusstyrka för att tillsammans representera våra bilder på bildskärmar.

Och då i och med att detta heltäckande nät dels består av kvadratiska klossar (se bild nedan):

bild på skärmupplösnings pixel-gridnät och pixeltäthet demonstrerat
Ovan bild hämtad från: denna sida

Såväl som att ofta (än så länge) idag kan inte bildskärmar uppnå upplösningar och pixeltätheter stora nog för att göra dessa klossarna tillräckligt små för att verka “smälta” samman  för våra mänskliga ögon (undantaget är eventuellt Retina skärmar som Apple har implementerat för många av deras produkter vid skrivande stund)- och därmed även kunna erbjuda t ex. seriferade typsnitt tillräckligt med pixlar för att kunna rättvist återskapa de dekorativa detaljer som de typsnitten har. Men eftersom detta inte är möjligt idag så kan seriferade typsnitt uppfattas som väldigt “korniga”/”kluddiga” – bild nedan:

serif brödtext vs sans-serif brödtext adlibris boktext som underlag
Ovan bild demonstrerar serifferat typsnitt (till vänster) jämte sans-serifferat typsnitt (till höger) applicerat på boktexts underlag hämtat från Adlibris. Notera skillnaden mellan de båda på webben. Man ser tydligen den högra texten klarare eller hur? För att göra det ännu tydligare ska vi zooma in och ta oss en närmare titt! Se nedan:
serif font vs sans-serif font demonstrerad för webb på adlibris boktext underlag
Ovan bild demonstrerar serifferat typsnitt (till vänster) jämte sans-serifferat typsnitt (till höger) applicerat på boktexts underlag hämtat från Adlibris. Notera hur tydligheten skiljer sig på webben mellan serif & sans-serif i ovan tydliga inzoomade exempel på 200% (klicka för att tydligare kunna se om för litet här i blogginlägget).

Och detta är då p.g.a. att pixeltätheten inte är tät nog (man brukar tala om ett begrepp kallat DPI som står för engelskans Dots Per Inches – där Dots är “punkter” på svenska och är en enhet som syftar till pixlar-per-tum – ett mått på pixeltäthet för skärmar med storlek angivna i tum helt enkelt), och gör därför att serifferna försöker återskapas på skärmen som väldigt små detaljer med det antalet pixlar som finns tillgängliga för just den skärmens upplösning och pixeltäthet, och har ni någonsin själva jobbat med eller pysslat med “pixelgrafik” så vet ni att cirklar t ex. kommer att se ut som nedan bild:

Pixelated cirkel - datorgrafik inzoomad.
Ovan bild demonstrerad pixelerad datorgrafik inzoomad. Notera hur en cirkel skapas med “kantiga” linjer p.g.a. upplösningen.

Och då kan ni säkert tänka er hur “otydliga” och irriterande seriffer kan bli för bildskärmar med tanke på att serifferna är ytterst små detaljer som då bara kan bli “hackiga” halv-dana liknelser återskapade med skärmar tack vare bristande antal pixlar att förfina detaljerna av serifferna för våra mänskliga ögon (Notera att om du tittar väldigt nära din bildskärmsyta på ett specifikt ställe/en specifik punkt så borde du kunna se små små rutor i alla möjliga färger (om du t ex. tittar på en vit skärmyta) även om du har t ex. 1920×1080 i skärmupplösning).

Och det är därför brukar man säga: Serifferade typsnitt för pappers-läsning av text, medan Sans-serifferade typsnitt för skärmläsning- då dessa helt enkelt blir renare och tydligare och då även resulterar i förbättrad läsvänlighet och läshastighet för människor jämfört med serifferade typsnitt på bildskärmar p.g.a. att ögat blir förvirrat och har svårigheter att följa texten.

Monospace typsnitt

För att sedan gå vidare till att tala lite kort om Monospace typsnitt innan detta inlägget är slut, så är monospace typsnitt väldigt populära i många sammanhang p.g.a. deras unika karaktärsdrag som är att: varje tecken som utgör typsnittet, har exakt samma längd (horisontellt), vilket gör att det kvittar vilka två meningar du skriver med vilka bokstäver du använder i meningarna, om båda meningarna har exakt identiskt antal mängd tecken. Då kommer dessa ta upp Exakt lika mycket horisontellt utrymme på skärmen!

Monospace typsnitt har därför blivit väldigt populära för utskrifter av kod såväl som tangentbords tangent-representationer m.m.

Ser man Monospace typsnitt vet man att det nästan alltid rör sig om koder eller något annat som är mer “tekniskt” i sin natur.

Allmänt typografiskt tips för webbutveckling

Där finns en gyllene regel för texter på webben som lyder att radmellanrummet (kan ställas in via CSS-attributet: line-height) bör vara 1.5em (em är en relativt procentuell måttenhet baserat på närmast angivna pixelstorlek i föräldraelement, kommer i detalj att gås igenom i framtida inlägg för css och CSS måttenheter), där 1.5em i stort sett innebär 1.5 * vad än man nu har för textstorlek på texten där radavståndet skall läggas in.

Jag brukar själv köra på denna regel oftast för mina egna sidor, funkar superbra och blir alltid väldigt enkelt och rent att läsa styckena på webbsidorna med regeln applicerat.

Val av typsnitt beror på hur säker du som designer/utvecklare vill kunna vara på att just ditt typsnitt är det som används för innehållet på din webbsida

Värt att känna till och ha i åtanke är att de typsnitt som fungerar för dig, fungerar inte nödvändigtvis för dina andra besökare. Detta är nämligen baserat på vilka typsnitt besökaren har laddat in till sitt operativsystem, MAC OS X, Windows och Linux har olika uppsättningar med “standard-typsnitt” som operativsystemen redan har förinstallerade.

Vill man vara helt säker på att besökaren kommer att kunna se ditt innehåll med just det typsnittet som du valde ut för webbsidan, så kan man antingen importera typsnitts filerna till själva webbsidan via ett CDN (Content Delivery Network), eller genom att implementera- och ladda upp typsnitts filerna (.TTF eller annat) till webbprojekts mappen och webbdokuments filerna. På så sätt så kommer de alltid kunna ladda in just ditt specifika typsnitt, dock kan detta bidra med en fördröjning och sinka ned hastigheten och webbupplevelsen för din webbsida då besökarna måste ladda ned typsnitten innan de kan se texter på sidan, alternativt kan alternativa typsnitt anges som används om förstahandsvalet skulle vara otillgängligt i stunden.

Slutkläm

Hoppas ni fann denna artikel intressant och att ni kanske fick lite utökad förståelse om typsnitt och hur dessa kan användas för olika syften som vid tryck, på webb eller för respentationer av olika typer av innehåll – såväl som varför specifika typsnitt är bra för specifika uppgifter.

Ses i nästa inlägg 😉

Hej igen alla webbutvecklings entusiaster och fantaster 🙂

Jag ansåg att Mozilla Firebug och Google Developer tools behövde en ordentlig genomgång- och har därför beslutat mig för att skriva ett dedikerat inlägg till bara dessa. Men tanken med detta inlägg är att gå in på djupet i båda utvecklingsverktygen.

Vi kommer gå igenom dess gemensamma funktioner för både Mozilla’s Firebug såväl som Google’s Developer Tools – då båda verktygen är ganska lika funktionsmässigt. Vi kommer gå igenom alla funktioner jag har haft användning för själv vid tidigare webbutvecklings projekt, samt sådana som folk visat ett intresse för att lära sig. Tror vissa av funktionerna kan vara speciellt främjande för er som precis börjat med webbutveckling och går någon data/it linje på gymnasiet. Dessa utvecklingsverktygen kommer underlätta er felsökning, stiländrings testning, prototype utveckling m.m. betydligt!

Poängen med dessa verktyg?

Poängen med både Firebug såväl som Developer Tools är att effektivisera och underlätta webbutvecklingsprocessen genom att direkt i webbläsaren, kunna erbjuda dig som utvecklare möjligheten att redigera och granska både HTML-kod, CSS-kod samt JavaScript/jQuery kod (man kan testköra javascript funktioner och liknande via en konsollruta i verktygen).

Granskning av komponenter (element) på en webbsida i realtid

Granskningen av komponenter på en webbsida låter dig avgöra hur webbläsaren tolkat och presenterat din webbutvecklings-kod, såväl som ger dig möjlighet att komma åt varje enstaka komponents/elements CSS-stilar i högerspalten. Se bild nedan:

Printscreen där CSS-stilarna visas i både Mozilla firebug såväl som Google Dev tools

CSS-stilarna visade i både Mozilla firebug såväl som Google Dev tools

Dessa stilar är mycket enkla att modifiera/ändra, och när du gör detta, så kommer dina ändringar att direkt visas i själva webbläsarfönstret! Detta banar väg för en ofattbart användbar och efterfrågad/smart funktion som underlättar och snabbar upp många uppgifter en webbutvecklare måste ta sig an.

Några av dessa skulle t ex. kunna vara att kunna testköra CSS-kod/HTML-kodändringar såväl som JS-Funktioner, m.m. – direkt i webbläsaren för ens webbsida.

Alternativa sätt att förhandsgranska kodändringar och nackdelar med dessa

Alternativt sätt annars att förhandsgranska kodändringar på hade ju varit t ex. att behöva ändra i CSS/HTML/JavaScripts faktiska kods dokumenten som sen dessutom även hade behövts sparas innan ändringarna skulle vara möjliga att förhandsgranska och eventuell laddas upp till en server/webbhotell beroende på vilken kod man jobbar med, och även då så hade det funnits risk i värsta fall att man hade behövt rensa cachen i webbläsaren (via t ex. [Ctrl + Shift + R] / [Ctrl + F5] / [Ctrl + R] – olika hotkeys för olika webbläsare/inställningar) för att vara på den säkra sidan att ändringarna verkligen visas såsom man kodade dem senast.

Rensning av cachen i webbläsaren kan behövas ibland har jag själv märkt då ändringar som gjorts och sparats i filerna inte verkar synas när man förhandsgranskar sidan direkt efter, utan de kommer efter en fördröjning, vad orsaken till detta är är jag dessvärre inte helt säker på. Då ger rensning av webbläsare-cachen en grundlig “reload” av webbsidan UTAN att ta hjälp av cachat material som annars kan förvirra och ge bilden av att inga ändringar gjorts, fastän de faktiska har blivit genomförda!

Rensning av cachen är det allra bästa sättet att försäkra sig på att inget sedan tidigare nedsparad kod påverkar resultatet av webbsidan man förhandsgranskar i stunden.

Eventuella nackdelar med att jobba i Firebug/Google Dev tools värda att vara uppmärksam på

Några saker man bör vara uppmärksam på är när man sitter och gör de här bekväma ändringarna i Mozilla Firebug och Google Developer tools, är det lätt att bli “för bekväm”, vilket ibland har hänt mig och lett till att jag helt plötsligt nästan tagit fram en helt ny stylesheet till en webbsida. När man har använt sig så pass mycket utav verktygen och gjort så pass många olika ändringar i verktygen så bör man vara väldigt försiktig med att klicka fel, eller råka uppdatera sidan man jobbat på – för så fort man gör detta, så försvinner alla ändringar om du själv inte har manuellt sparat undan dem allteftersom (vilket jag inte gjorde de första gångerna tyvärr ;p).

Detsamma gäller om sidan har en automatisk uppdateringstimer, eller om du skulle råka trycka på en källkodslänk som tar dig till en annan undersida, även då brukar stiländringar och kodändringar man gjort försvinna. Detta händer mest troligt då alla ändringar endast görs flyktigt och inte sparas i de faktiska filerna när man gör det.

Fördelarna som ges av att jobba med Firebug och Google Dev tools är överlägsna över nackdelarna

CSS-ändrings test och experimentation som man kan genomföra direkt i webbläsaren är definitivt guld värt och en av de främsta anledningarna till varför det är lönt att ta sig tiden att bättre sätta sig in i verktygen Firebug och Developer Tools.

Och det är då enbart en av de många fina funktionerna som verktygen erbjuder!

Hur kommer man då åt Mozilla Firebug och Google Developer tools i webbläsaren?

För att komma åt verktygen i webbläsaren på en viss webbsida så kan du göra som jag själv brukar göra med enkelhet – bara högerklicka på sidan på ett valfritt ställe (jag brukar sikta in mig på specifika element på sidan, så förflyttas jag direkt till det elementet i källkoden när verktyget öppnas), och därefter välja t ex.  ”Granska komponent” som det heter i Google Chrome, medan Firefox säger något liknande som ”Granska komponent i Firebug”. Se bild nedan som demonstrerar detta:

Öppna Google Developer tools via webbläsaren

Öppna Google Developer tools via webbläsaren

Verktygets gränssnitt och dess placering i webbläsaren efter aktivering

När du väl öppnat upp respektive verktyg kommer dess interface/gränssnitt att visas i botten av din webbläsare som en integrerad panel (såvida du inte ändrat något i webbläsarens standard-inställningar) som kan expanderas både uppåt såväl som reduceras nedåt.

Möjlighet finns att förflytta panelerna till höger/vänster sida av skärmen/webbläsaren, eller bryta loss panelen från webbläsaren till sitt eget webbläsarfönster helt och hållet om detta är en bättre lämpad placering för just hur ni föredrar att arbeta. Ändring av panelplacering brukar i Google Dev tools kunna göras via en knapp uppe i högra hörnet av panelen som liknar två skärmar placerade ovanpå varandra.

Panelen består annars av flikar med olika möjligheter och funktioner att nyttja för olika typer av granskning och analys av webbsidan, dess komponent(er) och koden som bygger upp den. Alla ändringar genomförs omedelbart i realtid, vilket jag personligen tycker är riktigt häftigt och väldigt användbart 😉

Redigera HTML-kod med Mozilla Firebug och Google Dev tools

Under flik-alternativen, till vänster har vi som standard HTML-koden placerad (d.v.s. om du t ex. öppnade panelen och verktyget genom högerklick och granska komponent) och för att kunna redigera och genomföra ändringar i koden här (oroa dig inte, ändringarna genomförs inte på din vanliga webbsida, bara i webbläsare-versionen av din webbsida) så högerklickar ni på den tagg/element som omfamnar det område du önskar redigera och väljer ”Edit HTML”/”Redigera HTML” eller liknande. Se bild nedan för Google Dev tools, respektive Mozilla firebug:

Redigera HTML-kod via t ex. Google Dev tools

Redigera HTML-kod via t ex. Google Dev tools

Redigera CSS-stilmalls kod i Mozilla Firebug och Google Dev tools

Ni har redan sett vart CSS-stilarna för element på sidan placeras i panelen i ovan printscreen – På höger sida av panelen kommer ni sen kunna se CSS-koden för vilket HTML-element som än har blivit markerat!

Högerspalten där CSS-koden står skriven brukar kunna scrollas ned ganska mycket- även om element inte fått tilldelat så många stilar av just dig, detta är för att verktygen även visar upp webbläsarstilar, såväl som andra stilmalls-koder du må använt för att ”normalisera” och eller övrigt påverka din webbsida och fixa kompatibilitets stöd för t ex. CSS3 kod som ännu inte stöds i alla webbläsare.

Med ”normalisering” menar jag en s.k. ”reset”/återställning av samtliga CSS-element till en fastställd standard att kunna utgå från UTAN de standardstilar som normalt sett gäller för HTML-elementen – typ som default-padding (standard utfyllnad av element), default-margins (standard marginaler/avstånd till andra element), standard typsnitt, teckenstorlek, etc. etc.

Du bör dock kunna se CSS-stilarna som du själv lagt till för ett element – oftast är dessa placerade överst, du har även möjlighet att direkt där i panelens del för CSS-kod kunna lägga till nya egna regler som direkt appliceras ovanpå webbsidan du granskar i verktyget. Detta är en väldigt kraftfull funktion som jag själv brukar använda för att testa nya stilar, och sen bara kopiera in i själva CSS-mallen när jag väl är nöjd med dem – går så mycket fortare och är så mycket lättare än att ständigt spara om och förhandsgranska på nytt.

Tips för snabbare redigering av CSS-stilarna i Mozilla firebug/Google Dev tools

Verktygen har möjlighet till en typ av “tabb-navigering” mellan CSS-attribut och attributvärde, vilket underlättar och snabbar upp skrivandet av CSS-stilar i CSS-panelen.

Alla stilmalls koderna i högerspalten kan ändras och längst ned i CSS-panelen kan man även se hur CSS-marginaler, borders såväl som padding har blivit applicerat på elementet du har markerat för att se CSS-stilar för.

För att redigera CSS-stilarna i verktyget kan det dock vara behjälpligt att sedan tidigare ha studerat CSS-kodning så man har en hyfsat god uppfattning om det, och kan skriva lite kod på egen hand. Annars finns det gott om guider och manualer ute på nätet att hämta inspiration och vägledning från.

Jag kommer även skriva inlägg om CSS-kodning senare framöver som i detalj kommer gå igenom de delar jag själv anser vara viktiga att känna till och kunna hantera.

Lägga till fler attribut för ett redan existerande CSS-kodblock

För att göra detta kan man placera sig med musen på ett av de redan existerande attributen och sen bara fortsätta att [Tabb]:a vidare tills man kommer till det sista attributet och dess attributvärde, därefter tabbar man bara en gång till för att inleda skapandet av ett nytt attribut + attributvärde! Väldigt enkelt, och väldigt användbart 😉

Lägga till nya CSS-regler/kodblock för sidan med Mozilla Firebug/Google Dev tools

Det brukar finnas en knapp i CSS-kods panelen som heter “Lägg till ny regel” eller något i den stilen, trycker man på denne så läggs en ny CSS-regel till, som brukar basera den nya CSS-regeln på HTML-elementet man hade markerat till vänster om CSS-panelen i HTML-panelen. Knappen brukar vara placerad ovanför det översta CSS-kodblocket i CSS-panelen i Mozilla Firebug och Google Dev tools.

Lägga till en ny CSS-regel för sidan via Google Developer tools

Lägga till en ny CSS-regel för sidan via Google Developer tools

JavaScript konsolfliken

Verktygen har ytterligare en funktion som många tycker är väldigt användbar, och det är Mozilla Firebug respektive Google Developer Tools ”Console Window” / Konsolruta. I denna kan man kalla på- och testköra JavaScript funktioner som finns tillgängliga i sidans redan inladdade JavaScript kod. Men även skapa egna funktioner direkt i console-fönstret. Väldigt användbart för realtids debugging av ens JavaScript kod.

Testkör JavaScript konsolfönstret i Mozilla Firebug och Google Dev tools

För att testa detta kan ni gå till fliken kallad ”Console” eller liknande, och där längst nere för den fliken, ser ni en ”>”-större-än tecken som vid tryck efter detta tecken- man ges möjligheten att skriva in egna kommandon och egen JavaScript kod.

För att bara testa så det funkar kan ni skriva in följande efter ”>”-större-än tecknet:

Och tryck sedan [ENTER] för att se console.log-meddelandet dyka upp i logg-listan ovanför fältet där ni skrev in koden. Se bild nedan:

Console.log testmeddelande för Google Developer tools

Console.log testmeddelande för Google Developer tools

Det kan hända här att webbläsartillägg som använder JavaScript skriver ut sina felmeddelande här – detta är en annan anledning varför konsolfunktionen är så användbar – så länge man har den öppen när man laddar en sida får man se om där finns några JavaScript felmeddelande för sidan (dessvärre verkar som sagt då även webbläsartilläggs felmeddelande komma med – men det kan då ses vilka felmeddelande som hör till webbläsartilläggen längst ut till höger där det står rad och fil som felmeddelandet hör till).

Direktlänkade klickbara filnamn och rader för vart felmeddelandena kom ifrån

Filnamnet och raden för vart felmeddelandet kommer från som syns längst till höger är klickbart och vid klick tar er till den exakta raden för JavaScript filen för webbsidan där felmeddelandet kom från.

Console.log populär JavaScript felsöknings funktion – bra och lätt att använda för test

Console.log som jag använde ovan för att demonstrera hur man kunde använda konsolfunktionen i verktygen är en “debugging-funktion” som existerar i JavaScript som är ganska populär och behändig att använda sig av för enkel felsöknings utskrift 🙂

Rensa konsolfönstrets felmeddelande logg

Om man har mycket felmeddelande som man vet är “onödiga”, så kan man trycka på den lilla ikonen högst upp i vänster hörn för konsolpanelen som liknar en cirkel med ett snett streck igenom, denne knapp rensar då hela felmeddelande loggen.

Användbar sökfunktion tillgänglig för att med enkelhet kunna identifiera specifika element för webbsidan

Båda verktygen har en inbyggd ”sökfunktion” där man i Google Developer Tools kommer åt denne genom att klicka på ett ganska litet (ser ut som ungefär 16×16 / 32×32 pixlar litet) förstoringsglas som är placerat högst upp i panelen till vänster, ganska svår att missa, medan i Mozilla Firebug den ser ut som en muspekare som klickar på en ”rektangulär ruta” – även denne högst upp till vänster i själva verktygspanelen, placerad bredvid Firebug-ikonen (till höger om den).

När ni har klickat på denna ”sök-ikon” så kan ni sedan dra musen till ett område på er webbsida (inte koden i Firebug/Google Developer Tools panelen – utan själva webbsidan och dess element i sig självt), och ni kommer förmodligen se en typ av ”highlight” att området ni håller musen över lyses upp och visar information om området, för att sedan markera detta område är det bara att klicka där ni håller musen, så kommer ni att direkt bli vidareskickade till det området ni markerade på själva hemsidan- i koden som finns tillgänglig i verktygets HTML-kods panel.

Se bild nedan för hur detta ser ut i Google Developer tools:

Demonstration av Google Developer tools sökfunktion

Demonstration av Google Developer tools sökfunktion

Detta är väldigt användbart för att hitta t ex. CSS-stilar eller förstå uppbyggnaden av HTML-element för någon annans webbsida snabbt och enkelt – såväl som för att kunna lägga till egna stilar för ett element för skoj skull 😉

Kreativ användning av Mozilla Firebug och Google Developer tools

Skräddarsy vilken webbsida ni än besöker utefter era egna preferenser utan problem!

En rolig sak som inte nödvändigt vis är för webbutvecklingssyfte är att ni själva kan skräddarsy vilken webbsida ni än besöker utefter era egna preferenser. Super användbart!

Besöker ni en sida där utvecklaren eller designern har valt att skriva texten med ett horribelt typsnitt? Inga problem, det kan vi enkelt råda bot på genom att identifiera elementen via Mozilla Firebug/Google Developer tools, som påverkas av typsnittet, och hitta roten i CSS-koden för vart typsnittet blir applicerat till dessa elementen, därefter kan vi gå in i CSS-panelen och manipulera/ändra attributvärdet till den font vi själva tycker känns trevligast att läsa på skärmen – vi kan till och med hämta in typsnitt från Google Web Fonts utan större problem (kan dock kräva lite extra ändring i CSS-panelen, eller i HTML-panelen för inhämtning av specifik font till sidan innan den kan användas).

Det är jätteroligt och kreativt att kunna använda verktygen på detta sätt 😀 Själv tycker jag det har hjälpt mig flertalet gånger då vissa webbsidor haft (enligt min åsikt) för liten typsnitts storlek – då har jag utan problem kunnat ändra det till en större storlek på samma sätt som jag beskrev i ovan stycke.

Gillar du inte färgerna på en webbsida? Gå in och ändra färgkoderna för specifika element, även det är enkelt 🙂

Allt detta, och mycket mycket mer kan göras med dessa verktygen, det är riktigt awesome 🙂

Praktiskt exempel av detta

Jag var tidigare inne på en sida hos WordPress Codex och kollade kommentarer folk hade publicerat till ett område, och ville då själv testa (lite i webbutvecklings syfte) hur det skulle se ut om inga s.k. ”avatars” visade sig till vänster om/bredvid kommentatorernas namn, så jag använde sökfunktionen i Google Developer Tools, klickade på profilbilden/avataren och gick sedan till CSS-koden och lade till ett nytt attribut kallat ”display: none;” vilket i princip ”tar bort” ett HTML-element från layouten av webbsidan – trots att elementet ligger kvar i koden (mer om detta i senare inlägg om CSS-kodning). Och då försvann samtliga profilbilder/avatars och jag kunde då se hur det skulle sett ut om de valde att ta bort det (eller i mitt fall- hur jag villa ha mina egna kommentarer presenterade för denna WordPress sidan ;)).

Slutkläm

Hoppas ni hade lika roligt som mig med det här inlägget, funderar på att eventuellt publicera “kortfilmer” i framtiden där jag via korta filmsnuttar demonstrerar ovan genomgångna funktioner såväl som nya kanske? Om detta hade varit något av intresse 🙂

Tills nästa inlägg- 🙂