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:

console.log("Detta är ett console.log meddelande jag själv skriver för att testa Mozilla Firebug/Google Developer Tools JS-konsoll funktion");

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 :D 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- :)

Jag var själv en person som brukade använda Pastebin.com väldigt mycket tidigare, p.g.a. dess enkelhet att kunna ladda upp kod med syntax highlightning för många språk… Detta var tills jag upptäckte en sida av pastebin.com som inte passade mig speciellt bra – när du t ex. behöver hjälp med studier eller affärsprojekt där det hade behövts delas kod, men koden inte nödvändigtvis får lov att ”läcka ut”, då bör ni undvika pastebin.com.

Detta säger jag då jag själv lade upp kod på pastebin.com och råkade senare snubbla över att min kod tydligen hade blivit sökmotoroptimerad omedelbart efter att jag hade valt att ladda upp den, den låg då alltså ute på Google och hamnade högt upp på sökresultaten om man sökte i närheten av vad min paste hade varit döpt till, vilket var väldigt deskriptivt och sökmotorvänligt. Detta då jag inte trodde att det skulle sökmotoroptimeras och jag kunde beskriva problemet jag hade lite kortfattat i paste-namnet.

Hursomhelst, om ni pysslar med lite delikatare koder som kanske inte nödvändigtvis skall poppa upp överst på Google, så bör ni nog kanske undvika pastebin’s koddelning, i övriga fall så kvittar det nog om ni inte har ett behov av att hålla koden lite privatare.

Pastebin.com är i övrigt en väldigt populär och bra koddelningssajt som dagligen har tusentals om inte miljontals aktiva koddelare och användare.

Tänkte iaf. informera om detta, då jag tror det är fler än mig som än idag är ovetandes om detta, och det kanske inte har så stor betydelse för många av er, men där finns säkert någon där det har det.

Några bra alternativ jag kan föreslå istället för att dela kod är t ex. Codeshare.io, som är ett realtids koddelnings och kollaborations verktyg online där du och dina kollegor samtidigt kan vara inne i ett interaktivt koddokument på nätet med din kod där alla kan i realtid ändra och föreslå ändringar i koden – typ som Google Docs, fast för kod ;).

Ett annat är JSFiddle.net (främst för webbutveckling dock tror jag).

Båda dessa verktygen och flera kan hittas på denna bloggs Länkar-sida.

Tänkte att jag skulle informera åtminstone utifall där finns fler ovetandes som hade haft nytta av kunskapen.

Bästa hälsningar, :)

 

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.

Jag som kommer skriva inlägg på denna sidan är för tillfället anställd som Full-stack webbutvecklare för ett e-handelsföretag parallellt med att bedriva egen verksamhet som konsult inom data/IT och webbutveckling. Dessförinnan var jag universitetsstuderande på distans inom områdena datateknik, webbdesign och webbutveckling på diverse högskolor och universitet i olika delar av Sverige.

Jag har haft ett brinnande intresse för både datorer såväl som webbdesign och webbutveckling ända sedan jag gick i grundskolan, och nu har jag äntligen lyckats uppnå en kunskapsnivå där jag känner mig tillräckligt säker på väldigt många av de områden som spelar in på att skapa en fullfjädrad hemsida med diverse tekniker och teknologier som finns till ens förfogande idag.

Min förhoppning är att, via denna sida, kunna dela med mig av min passion till andra som också har ett intresse för webbdesign och webbutveckling och allt vad området innefattar.

Samla allt för webbutveckling på ett centralt ställe

Jag kommer att förse läsare med material som främjar egen vidareutveckling inom ämnet. Detta då jag själv nuförtiden ibland tittar tillbaka och önskar att jag hade haft tillgång till en sida såsom den jag tänker skapa här – med allt det viktigaste samlat på en central plats.

Med tillgång till: resurser, vägledning och väl-förklarade inlägg om hur man lär sig mer inom området, och successivt kan ta sig från nybörjare till proffs. Såväl som länkar till resurser, referenser och användbara verktyg samt läsvärda artiklar!

Sidan är inte enbart avsedd att förse er läsare med bra material, utan kommer även att agera samlingssida för mina egna äventyr inom området- såväl som fortsatta studier och vidareutvecklingar inom webbdesign och webbutveckling :)

Allt jag tror kan vara av intresse för er, såväl som det har varit för mig, kommer att publiceras här!

Mitt syfte med sidan

Ett citat som känns väldigt träffsäkert för mitt syfte med denna sida är:

”Gör för andra, vad du önskar andra gjort för dig”

Det är detta jag kommer sträva mot att ständigt uppfylla med den här sidan.
Förse er med material som jag önskar att jag hade kunnat ta del av på ett samlat ställe i början av resa och min tid som webbutvecklare.

Sidans innehållsspråk

Då svenska är mitt modersmål kommer inläggen i förstahand att skrivas på svenska, men engelska motsvarigheter för de svenska inläggen kommer också att skrivas allteftersom för att göra innehållet tillgängligt för fler.

När det gäller undersidorna som t ex. ”Länkar” så kan det hända att beskrivningar för specifika länkar är skrivna på engelska, detta då det vid skrivande stund ansetts enklast.

Egen slang på sidan

Ordet ”Webbdev” kan förekomma en del på diverse ställen på sidan. Detta är min egen samlingsterm för att definiera de sammanslagna orden ”Webbdesign och webbutveckling”, då det är ganska långt och otympligt att skriva ut alla gångerna.

Smakprov på vad sidan kommer ha att erbjuda

Några område såhär på rak arm som redan är planerade att skrivas om är som följer:

  • Webbdev baskoncept
  • HTML5 [& Semantisk markup]
  • CSS
  • JavaScript [& jQuery]
  • PHP
  • Databaser
  • Responsiv webbdesign
  • Sökmotoroptimering (on-page främst)
  • CMS & WordPress
  • Versionshantering av kod med Git & GitHub
  • Utvecklingsmiljö och programvara
  • Programmerings grunder
  • Facklitteratur och böcker
  • Övrigt
  • Webbhotell & Hosting
  • IRC för supportnätverkande
  • Google Analytics
  • Google Web Fonts
  • Användbar webbutvecklings matematik
  • Användbara datorkunskaper för webbutvecklare
  • Användbara kunskaper för att studera på universitetsnivå

… för att nämna några :)

För mer detaljerad information kring vad jag planerar att ta upp och gå igenom på sidan, kan ni besöka undersidan: ”Framtidsplanering: inlägg”. Kommer att uppdatera denna allteftersom :)

Feedback från er läsare

Jag uppskattar konstruktiv kritik för att hjälpa mig bli bättre på skrivandet av inlägg, etc. Speciellt såhär i början av mitt ”bloggande”.

Och jag tar även gärna emot förslag och önskemål, så tveka inte att höra av er, antingen via kommentarsfältet som kommer att vara tillgängligt från diverse ställen på sidan, eller på contact[at]webbdev-essentials.net , ser fram emot att dela med mig av mina kunskaper till alla er läsare :)

Tills nästa inlägg,
Bästa hälsningar,
Trekka12

En viktig del inom webbutveckling som många glömmer (eller inte ens känner till) är: bilder och presentation av bilder i korrekta proportioner för att inte ”skrynklas” och bli förvrängda och tappa kvalitet.

Jag kallar detta område för bildproportioner förklarat då jag syftar till att informera om enkla matematiska formler som praktiskt taget kan göras via huvudräkning för att ta reda på vad en bild skall ha för ny bredd, respektive höjd vid förminskning, för att behålla originalbildens proportioner.

Förstoring av en bild brukar bli kasst oavsett om man behåller proportioner eller ej, fast såklart- mindre kasst om man behåller proportionerna.

Formlerna kan liknas vid det som automatiskt görs i t ex. Photoshop bildredigerings programmet när man har ikryssat rutan för att behålla bildproportionerna.

Det är dock inte alltid man har Photoshop tillgängligt, därför tänker jag att det kan vara användbart att känna till en bakomliggande formel för hur man själv kan göra samma sak på egen hand vart man än befinner sig/vad man än har att jobba med :)

Vår Exempelbild att skala om

Vi kommer utgå från att vi har en bild vars dimensioner är som följer:

Bredd är 430 pixlar medan Höjden är 275 pixlar.

Alltså: 430 x 275 som ursprungliga ”grund” dimensioner. Detta för att visa att det går att applicera vår formel på alla bilder, oavsett dimensioner.

Vi kommer i exemplet välja att förminska vår originalbild till ett proportionellt nedskalat alternativ.

Räkna ut Nya proportionerliga dimensioner för vår bild

Vår formel går ut på att vi väljer antingen en förutbestämd höjd (eller bredd för den delen) och sedan utifrån vårt nya valda dimensionsvärde (höjden/bredden), räknar vi ut det andra dimensionsvärdet.

Detta är speciellt användbart och praktiskt i webbutveckling då man t ex. sitter med en originalbild som är väldigt stor och man bara vill se hur den skulle se ut med mindre proportionella dimensioner som bättre passar in i ens egna sidlayout.

Då kan det vara användbart och bra att kunna på direkten räkna ut motsvarande bredd, eller höjd – utifrån det andra värdet man valt.

T ex. om ni tänker er att ni har en sidlayout där bilderna måste vara 200 pixlar höga, så behöver ni då räkna ut en proportionell motsvarighet i bredd.

Eller om ni ska göra ett galleri och ni vet att varje bild måste vara en fast bestämd bredd, t ex. 325 pixlar, medan höjden är tillåten att flexibelt variera (detta hjälper att hålla bilderna proportionella).

Stega igenom formeln och processen

Välja vårt ena dimensionsvärde

För detta exemplet tänker jag bygga på ovan praktiska exempel där vi hade en höjdbegränsning på 200 pixlar för bilderna till vår sidlayout.

Räkna ut vårt ”förhållande-värde” för nya bilden till originalbilden

Om vår originalbild nu var 430 pixlar bred, och 275 pixlar hög, och vi nu måste minska bilden till 200 pixlar i höjd, så kan vi få 2 olika förhållande-värde mellan originalbilden och den nya bildens dimensioner: antingen originalbild -> nybild, eller nybild -> originalbild.

Vad detta då innebär är att man dividerar t ex. originalbildens höjd med nya bildens höjd, eller tvärt om. I vissa fall blir det ena enklare än det andra.. Det märker man med tiden allteftersom man gör det mer och mer. Jag kommer visa varför längre ned, se nedan exempel för förhållandet vi väljer i det här fallet:

höjdförhållande för proportionell bildförminskning

Höjdförhållande för proportionell bildförminskning

Det fanns en baktanke också varför vi valde att göra det just i den här ordningen.

Med Nya bildens höjd som täljare, och originalbildens höjd som nämnare– nämligen av anledning att när vi sen skall räkna ut breddförhållandet så blir det enklare att lösa ut den okända nya bredden (x) om den står i täljaren, än om den stod i nämnaren – simpel algebraisk bråkräkning :)

Värdet vi fick ut av ovan uträkning är vårt förhållande-värde, och vad som är speciellt med detta, är att det måste vara exakt samma för både bredd-förhållandet- såväl som höjd-förhållandet, om vi vill behålla proportionerna till vår originalbild för de nya dimensionerna av bilden.

Algebraisk ekvationslösning för att få ut resterande nya dimensionsvärdet

Vad som nu återstår är att med hjälp av algebraisk ekvationslösning lösa ut den nya bilddimensionens proportionella bredd-värde genom att utföra följande uträkning:

uträkning för bredd-förhållandet via algebraisk ekvationslösning

Uträkning för bredd-förhållandet via algebraisk ekvationslösning

Som ni då sen ser ovan så ger detta oss alltså en proportionell ny bildbredd på 313 pixlar avrundat uppåt.

Vilket innebär att vår nya förminskade bilds dimensioner ska vara: 313×200 för att vara så nära proportionell mot originalbilden som möjligt (säger ”så nära proportionell som möjligt” då som ni ser ovan så hade vi 312.73 och inte 313 pixlar som ny bredd – dock är det bäst att man anger bredd i HTML för bilder med heltal, + att det inte är ”så mycket skillnad” egentligen).

Distorsion och förvrängning

Varje gång en bild skalas om till nya dimensioner (framförallt vid förminskning) – speciellt om de nya dimensionerna inte proportionellt matchar originalbildens dimensioner, så tappar bilden kvalitet!

För att undvika detta kan man i vissa fall använda sig av SVG (Scalable Vector Graphic / Vektorgrafik) istället, som alltid behåller exakt samma kvalitet oavsett hur mycket- eller lite- man än skalar om bilden. Annars får man helt enkelt vara uppmärksam på hur man skalar om sina bilder och försöka behålla proportionerna till originalbilden så gott det går :)

Slutkläm

Såja, då vet ni hur ni kan göra det Photoshop annars gör åt er på egen hand + att ni fick repeterat gymnasiala matematik-kunskaperna ^^

Hoppas ni fann detta inlägg lärorikt och intressant, och att ni kanske får nytta av det någon gång framöver :) Enjoy ^^