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.

Två attribut som gäller för i stort sett alla HTML-taggar är attributen: id och class.

ID attributet: används för unik identifiering av ett element på en enstaka webbsida, vilket betyder att samma ID-värde får enbart finnas för 1 specifikt element på en hel webbsida!

Medan class attributet kan finnas på flera element på samma webbsida.

Båda attributen används för att identifiera, och välja (eng. select) taggar från t ex. CSS-kodning eller JavaScript kod.

ID-referens ger även Lokala ankar-länkar

ID attributet kan även användas för att specificera specifika s.k. ”lokala ankar-länkar” till en sidas innehåll. T ex. om du har en artikel på din sida med 5 olika stycken, och du vill kunna länka till var och ett av de specifika styckena, då kan man ange ett ID attribut till HX taggarna om varje stycke har en headline dvs. eller bara till Paragraf taggarna själva. Mer om detta kommer att gås igenom i ett inlägg om HTML länkar som jag kommer skriva lite längre fram! Se nedan exempelbild.

lokala ankarlänkar via id

Lokala ankarlänkar via ID i URLen

Praktiskt exempel

Som ett praktiskt exempel kan ni ju föreställa er om ni har en webbsida med 15 st. paragrafer, och ni vill lägga på speciella stilar för paragraf #10 av de 15 som finns på sidan, hur hade ni då kunnat ”sikta in stilarna på just den taggen”? Jo, antingen hade ni gett paragraf #10 id attributvärde så att den kan hittas från CSS/JavaScript via ID:t, eller så hade man gett paragraf #10 ett class attributvärde.

Enda skillnaden är att om ni sen skulle komma på att samma stilar hade sett snyggt ut för även paragraf #2, #5 och #8, så hade ett ID attribut inte kunnat anges på flera olika element på samma sida! Däremot hade ett class attribut kunnat anges på flera element på samma sida(!), och därmed hade alla elementen med samma class attributvärde, delat samma stilar!

Användning av flertalet Klasser/ID:n för ett och samma HTML-element

Denna praktik kan vara användbar om man har många olika separata klasser som var och en håller delar av stilmalls kod som man vill använda tillsammans för ett och samma element, utan att ange en ny klass där stilarna från t ex. 2 olika klasser skrivits om på nytt för att kunna finnas sammansatta, istället kan man ange multipla klasser/id:n genom att separera vart och ett med ett simpelt mellanrum som attributvärde.

Se exempel nedan:

<div class="klass1 klass2 klass3 klass4"></div> <- denna div får stilarna från klass1, klass2, klass3 och klass4.

<div id="id_1 id_2 id_3 id_4"></div> <- denna div får stilarna från id_1, id_2, id_3 och id_4.

Ett lite mer praktiskt exempel hade kunnat vara:
<div class="fontArial colorGreen fontSize13px normalPadding"></div> 

Ovan div och allt den innehåller får stilar från klass: fontArial, colorGreen, fontSize13px och normalPadding.

Sammanfattning

Så sammanfattat- Vad är då poängen med ID jämfört med Klasser?
Jo, ID använder man om man är säker på att referensen endast behöver/kommer att göras endast en gång! Klasser är till för motsatsen -> När du vet säkert att samma stilar eller samma typ av referens kan komma att behöva återanvändas på fler ställen på samma webbsida!

Så nu har ni fått en ”Crash Course” i även Klasser och ID:n ;) Enjoy :) Ni kommer att ha stor användning av kunskapen om dessa framöver!

Var man skriver HTML-koden för sin egen webbsida

Man kodar hemsidor i texteditorer, som t ex. Notepad, Notepad++, SublimeText, eller annat program, det finns även IDE’s (Integrated Development Environments), som stödjer HTML-kodning.

Vissa har mer funktioner och finesser än andra, själv föredrar jag att koda i Notepad++, användarvänligt, enkelt, rent och praktiskt(!) Men vanliga Notepad hade funkat lika bra till en början :)

Hur man sparar HTML-kod inför granskning

När man väl skrivit sin HTML-kod i ett textdokument så sparar man textfilen som filtyp med filändelsen .html för att göra textfilen till en webbdokuments fil, närmare bestämt en HTML-fil.

Förhandsgranskning av HTML-kod i webbläsaren

När ert textdokument med HTML-kod väl blivit sparat som en .html fil, så brukar det vara intressant att se hur koden man skrivit ser ut i en webbläsare.

Detta kan göras ganska enkelt genom att öppna den nyligen sparade .html filen med en webbläsaren – vilken ni än har tillgängligt på er dator, om det så är: Google Chrome, Mozilla Firefox, Oracle Opera, Apple’s Safari, eller annan.

Tänk dock på att olika webbläsare kan skilja sig i hur de ”översätter och tolkar” er HTML-kod.

Olika definitioner/inställningar i olika webbläsare

Detta då olika webbläsare har olika inställningar som t ex. ”hur stor är 1 enstaka pixel” (vilket kan leda till olika layouter i olika webbläsare), eller ”om inga CSS-stilar angetts, hur skall HTML-element av den typen stil-sättas?”, m.m.

Där finns vissa skillnader mellan t ex. Mozilla Firefox och Google Chrome, men sen många år tillbaka har den som orsakat mest problem p.g.a. skillnader till andra webbläsare varit (ja, ni gissade rätt): Internet Explorer..

Internet Explorer börjar dock faktiskt bli bättre när det gäller översättning och tolkning av webbkod, dock kvarstår fortfarande problem på vissa fronter när man utvecklar för att det ska se ”likadant ut i samtliga webbläsare”, då vissa fortfarande är envisa med att byta från äldre versioner av Internet Explorer..

Varierat media stöd mellan olika webbläsare

Olika webbläsare stödjer också olika mediatyper för uppspelning av film och ljud – detta kommer vi gå igenom senare när vi börjar bli lite mer avancerade om hur man kan ”komma runt” detta, men för tillfället kan det vara bra att bara känna till att det finns skillnader för detta.

Därför kan det vara smart att kontrollera hur er webbsida ser ut i flertalet webbläsare – man kan ju trots allt ha hur många olika typer av webbläsaren man än vill på en dator.

Webbverktyg för webbläsar kompabilitets kontroll

Ute på nätet finns ett antal verktyg man kan använda för att genomföra just sådana här kontroller om hur ens webbsida ser ut i andra webbläsare (tror dock att ens webbsida först måste vara uppladdad till nätet isf.), sådana verktyg kan hittas på vår: ”Länkar” sida. Kolla efter BrowserStack eller annat webbverktyg.

CSS-reset för nollställning av webbläsares standard CSS-stilar

Senare när vi kommer börja gå igenom CSS kommer vi gå igenom något som kallas för ”CSS-Reset” och detta syftar till en framtagen testad, väldigt grundläggande CSS-kod som har i uppgift att ”nollställa” alla ”standard-stilar” som webbläsare har för element som inte har fått några stilar definierade specifikt av er själva som utvecklare – detta hjälper er då att få en ”clean-slate”/”blank-canvas” så man kan börja helt från scratch :)

Validera sin HTML-kod: Vad, varför och hur?

Validering av HTML-kod är en kontroll man kan göra för att försäkra sig om att man inte kodat fel någonstans enligt vad kodningsstandarden man valt dikterar som godkänd kod.

Varför vill/behöver man då validera sin kod? Jo, det är ganska smart att göra detta för att försäkra sig om att man inte har någon felaktig bit av kod som orsakar problem som i sin tur förstör för hur besökare ser ens webbsida, eller förstör för annat man försöker koda in på sin sida.

Dessutom kan det spara en väldans massa tid ”down the road” om man regelbundet validerar sin kod för att försäkra sig om att inga misstag begåtts under utvecklingsprocessens gång.

Det är väldigt bra att försöka göra rätt från början helt enkelt, besparar en från en hel del ”huvudbry” som annars kunnat komma djupare in i utvecklingsprocessen.

Hur Validerar man då sin kod? Jo, W3C (World Wide Web Consortium) har egna validator-verktyg som ni kan hitta på: https://validator.w3.org/

Ni går bara in på den sidan och sen väljer ni om ni vill 1. validera en fil genom att ladda upp den specifika fil ni vill validera, eller väljer ni att 2. validera en redan publicerad sida som redan finns ute på nätet genom att klistra in länk-URL:en/URI:en (Uniform Resource Locator/Identifier).

För utvecklingssidor man håller på med kan man: lägga in en länk på sin sida med en ”egen-referens” till validator-verktyget, vilket i sin tur innebär att allt man behöver göra är att klicka på den länken för att direkt få just den sidan man kom ifrån – att bli validerad. Referensen i själva länken pekar på sidan man kom från med andra ord, väldigt praktiskt och användbart!

Detta är i synnerhet väldigt användbart för att ha för validering av ens egna sidor medan man håller på att utveckla! En sådan länk ser ut som följer:
<a href=”http://validator.w3.org/check/referer”>HTML5</a>

Så även detta är en God Praxis att ta efter! ;)

En webbsida i sin simplaste form består av tre taggar/områden (ev. fyra – se slutet av inlägget).

DTD – Document Type Definition

Denna indikerar vilken typ av kod-dokument/kod-standard webbläsaren skall tolka.

Detta är nödvändigt då varje gång en besökare besöker en webbsida i webbläsaren så är det webbläsaren som läser igenom och ”översätter” källkoden till det slutresultat som sen presenteras för besökaren.

För HTML5 ser denne ut som följer:
<!DOCTYPE html>

Väldigt ren och simpel, jämfört med tidigare för XHTML t ex. som var ganska otymplig/klumpig att skriva varje gång man skapade ett webbdokument:
<!DOCTYPE html
     PUBLIC ”-//W3C//DTD XHTML 1.0 Strict//EN”
     ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
DTD:n skall stå med i ALLA webbdokument man skapar! (för HTML5, skall HTML5 DTD:n stå med överst i webbdokumentet)

<head> området

Andra delen är <HEAD> taggen och HEAD-området för webbsidan, detta är den del som en besökare inte direkt kan se innehållet av, utan att inspektera källkoden!
– Här placeras allt från inkludering av CSS-stilar, länk till favorit/bokmärkes- ikon, implementering av Google Web Fonts, Meta-data sökmotoroptimerings taggar, webbsidans <TITLE> (som har hög profil när vi pratar sökmotoroptimering), inkludering av JavaScript (ibland), m.m.

<body> området

Sist men inte minst kommer <BODY>-taggen och BODY-avdelningen, som är den del av webbsidan som håller allt som besökaren ska kunna se när webbsidan presenteras/tolkas av webbläsaren.
– Här placeras hela webbsidans struktur, alla HTML-taggarna som bygger upp webbsidan, länkar och allt som skall vara ”synligt” för besökare!

<title> taggen

Man skulle kanske även kunna kalla <title> taggen för en av de fundamentalaste delarna, då det (förr iaf.) var krav på att ha med denne tagg i HEAD-avdelningen för en webbsida.

Att inspektera HTML-kod för webbsidor du besöker i webbläsaren, brukar inte vara svårare än att högerklicka på webbsidan, och välja ”inspektera-källkod”, eller granska källkod, eller liknande. Källkoden för en webbsida brukar oftast syfta till HTML-koden (kan även inkludera JavaScript och CSS-kod dock).

I Google Chrome verkar alternativet heta ”Visa sidkälla” såvitt jag kan se just nu i version 41.

För att sen leta sig fram till specifika element finns där tricks man kan använda sig av, t ex. [CTRL + F] för ”find”/hitta på svenska, för att hitta/identifiera antingen text som står skriven på webbsidan, eller kanske element man är ute efter.

På detta sätt att inspektera hur andras källkod ser ut kan man lära sig mycket om att skapa egna webbsidor, genom att lära från hur andra gjort det, man kan till-och-med låna av deras källkod om man hittar något man gillar(!). Var vaksamma här dock så ni inte ”lånar” något som ni inte har tillåtelse till! Vissa är okej att man lånar kod från deras sidor, andra är inte lika okej med det..

Se till att ni vet vad som gäller innan ni gör något :)

Mer avancerad och praktisk inspektion av källkod

Idag finns en mer avancerad form av inspektering av källkod som jag kommer ta upp i ett helt eget inlägg som sen kommer att länkas till härifrån när väl publicerat. Detta sätt är nämligen granskning av komponenter via antingen Google’s Code/Web Inspector (tror jag det heter), eller Mozilla Firebug och liknande. Dessa verktyg har blivit något av min egna preferens för inspektion av källkod det senaste året, då de erbjuder ett väldigt brett utbud av användbara och bra funktioner!

Mer om dessa senare som sagt :)