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:

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

 

Tjenare alla läsare!

I detta inlägg hade jag tänkt gå igenom hur vi bygger upp en webbsida från grunden utifrån en framtagen skiss steg för steg, med förklaring av var steg på vägen :)

Detta är en väldigt viktig kunskap att ha och känna till, speciellt om ni siktar på att jobba lite mer ”professionellt” inom webbutveckling framöver.

– För att styrka vad vi tidigare visat upp med indentering för lättläsligare kod, såväl som HTML5 semantiska element för bättre markup, så kommer vi i detta inlägg använda oss av dessa principer som visats i tidigare inlägg.

Vi kommer att använda oss utav de följande HTML5-elementen för att märka upp vår sida: <header>, <nav>, <article>, <section>, <aside> och <footer>

Detta är dock bara tippen av isberget, den allra första ”mallsidan” som sen kan kopieras och återanvändas till även resterande sidor för vår webbplats.

Låt oss börja med vår skiss av webbplatsens layout!

Ni kan göra er egen skiss om ni vill avvika lite från den layout jag kommer att använda här i detta exemplet. Då kan ni sedan se hur jag bygger upp min skiss i HTML, så kan ni sen göra detsamma med er egen! :)

Visualisera och planera hur ni vill att er webbplats layout skall vara

Wrapper-div för att binda samman alla element till samma layout

Låt oss göra en väldigt basic skiss som har en ”wrapper-div” som omsluter alla våra HTML5-element som skall bygga upp vår sida så att de ”binds samman” till en och samma layout-behållare (vår wrapper that is).

Sidhuvud inkluderat logotype, kontaktinfo och nav-meny

Sedan vill vi även ha en <header> överst på sidan, inuti vilken vi tänker ha en Logotype, samt den viktigaste kontaktinformationen till mig/er/ett företag, och undertill skapar vi sedan en horisontell <nav> meny.

2-kolumns layout för innehålls-delen för sidan

Därefter skall vi ha vårt innehåll, och då tänker jag köra på en 2-kolumns layout där vänster-kolumnen utgör vår sidans själva innehåll, medan högersidan utgörs av vår <aside>-sidebar.

Sidfot inkluderat Copyrighttext + eventuella ”mini-knappar” till övrig info för sidan

Under dessa 2 kolumner vill jag ha min <footer> som skall innehålla bland annat en Copyrighttext och ev. ”mini-knappar” till extra information om webbsidan eller relaterade delar.

Skissa…

Jag kommer att skissa upp min webbsidas layout i Microsoft Paint (mspaint CMD) i Windows 7, men ni kan likaväl använda Photoshop, GIMP, ett vanligt papper, eller annat ritprogram, eller vad ni än själva föredrar :) Det viktigaste är att ni själva kan få en bild av hur ni tänkt er att sidan ska se ut, som ni sedan kan referera till under utvecklingsprocessen.

Skissen är mer för er egen skull än någon annans, det är ju trots allt er ”ritning” av hur ni skall bygga upp er webbsida.

Se hur min skiss blev med inkluderade anteckningar om layoutens detaljer nedan:

Min skiss av webbsida struktur för verklig hemsida

Som ni kan se har jag inkluderat en hel del detaljer – och av dessa detaljer att döma så verkar webbsidan jag avser att skapa- likna en bloggsida/företagssida eller något i den stilen.

Hursomhelst, min skiss är detaljerad mest för er skull, men även lite för min egen så att om jag kommer på vilka detaljer av sidan som skall gälla när jag väl skissar sidan, så kan jag även komma ihåg dem/ha en referens till dessa(!). För när jag väl börjar jobba med att bygga upp strukturen för webbsidan kan det vara behändigt att ha dessa tillgängliga att referera till.

Börja realisera layouten i faktisk HTML-kod!

Steg #1 – Låna inspiration från tidigare HTML5-mall vi gjorde

Så, då t ycker jag vi är redo att påbörja arbetet ;) Jag kommer att börja med att låna mallkoden från HTML5Doctor som vi gick igenom i inlägg: Introduktion till HTML – Basic Boilerplate/template/mall att utgå från.

 

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
</body>
</html>

Kom nu också ihåg att vår CSS-stilmall som inkluderas kommer att än så länge endast innehålla Eric Meyers CSS-Reset v.2.0 (vilket inkluderar HTML5Doctors-mallens On-page CSS-block kod för normalisering av HTML5-element): http://meyerweb.com/eric/tools/css/reset/.

CSS-stilarna för denna webbsidan kommer att gå igenom i ett separat inlägg för att kunna fokusera på vår struktur i det här inlägget, annars hade detta inlägg blivit alldeles för långt är jag rädd. Jag kommer att försöka länka till inlägget med CSS-stilarna för detta inläggets sida i slutet av denna post så ni med enkelhet kan hitta dit.

Steg #2 – Omsluta sid-elementen i en Wrapper

Nu när vi har vår grundmall (skönt att slippa skriva om den och googla om man glömt sen tidigare – sparar en hel del tid (dock om ni skulle vara helt nybörjare i webbdesign och webbutveckling Råder jag er att skriva mallen för hand(!), istället för att kopiera koden rakt av – gör alltid detta för moment ni är ovana vid, skriv det tillräckligt många gånger och jag lovar er att förståelsen hakar på efterhand)), så har det blivit dags för att lägga in vår ”Wrapper-DIV” för sidan som skall omsluta alla våra HTML5-element som skall utgöra själva strukturen av vår uppskissade webbsida.

Det är väldigt god praxis att alltid ha en Wrapper-Div av många anledningar, varav ett exempel är att det blir enklare att styra vart var och ett av våra HTML5-Element skall placeras på skärmen med hjälp av CSS senare.

Se nedan HTML5-kod för mall + vår ”Wrapper-DIV”:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper"> <!-- Here starts our Wrapper DIV -->
    
</div> <!-- Here ends our Wrapper DIV -->
</body>
</html>

Notera att kommentarer jag inkluderar är för er förståelses skull främst. Brukar normalt sett annars inte ha med dessa typer av kommentarer då jag anser att det endast brukar bli nödvändigt vid djupgående hierarkiska strukturer då man t ex. behöver förtydliga vart somliga DIV-behållare slutar, och vart andra börjar (oftast är det dock bara slutet av en behållare man är intresserad utav).

Steg #3 – Generell yttre struktur

Nice, då är vi klarar med vår Wrapper-Div, dags för nästa steg – vilket blir att skapa själva strukturen inuti denna wrapper. En struktur som utgörs av en <header> tagg, en ”content-behållare-wrapper” med <article> tagg och en <aside>-sidebar, såväl som vår <footer> tagg.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper"> <!-- Here starts our Wrapper DIV -->
    <header> <!-- Here starts our Header -->
        
    </header> <!-- Here ends our Header -->
    <section id="content-wrapper"> <!-- Here starts our Content-Wrapper-Section -->
        
    </section> <!-- Here ends our Content-Wrapper-Section -->
    <footer> <!-- Here starts our Footer -->
        
    </footer> <!-- Here ends our Footer -->
</div> <!-- Here ends our Wrapper DIV -->
</body>
</html>

Som ni kan se ovan byggde jag vidare på vår ”wrapper-Div” så den nu har <header>-området, såväl som en ”content-wrapper-section” där vi senare skall placera vår <article> såväl som <aside>-sidebar. Anledningen att jag lagt en ”inre wrapper” även där för att omsluta även dessa på en närmare nivå, är också för hjälp med positioneringen och utökad kontroll över våra HTML5-element.

Notera att jag tilldelat båda våra Wrappers fetstil såväl som ID-attribut för att senare i CSS kunna med enkelhet urskilja dessa såväl som att mer precist kunna sikta in oss på deras barn-element som de omsluter.

Ovan kodsnutt demonstrerar även hur jag tänkt i mån av syntax highlightning för att lättare kunna visa för er de olika delarna i HTML-koden, taggarna kommer att vara fetstilsmarkerade med mörkgrå färg, textinnehåll kommer få blå färg, kommentarer kommer även dessa bli fetstilsmarkerade, fast med en mildare grå färg då kommentarerna inte är den kod av mest vikt i exemplet, och behöver därför heller inte uppmärksammas lika mycket. HTML-attributen kommer att markeras med grön textfärg, medan deras attributvärden kommer att bli svart-markerade för att lättare urskiljas.

Nu går vi vidare till att fylla vårt <header>-område med ytterligare innehåll och delar av sidan:

Steg #4 – Fylla Sidhuvud med innehåll som: Logo + slogan, Kontaktinfo & Meny

Jag ville ha en Logotype såväl som ett litet område där jag kan placera kontaktinformation som kan vara lättillgängligt för alla besökare att ta del av – och det är dessa delar vi skall koda i denna del av inlägget.

Jag väljer också att ha en Text-&-CSS-Baserad Logotype på sidan med <h1> tagg för sökmotoroptimeringens skull såväl som en liten tillhörande ”slogan” undertill vår logga.

När det gäller kontaktinformationen så kommer denna att omslutas inuti en <section> där själva kontaktinfon kommer att formateras som antingen en <table> tagg eller <ul>-lista eller <p> tagg som håller informationen.

Alla val jag gör av att presentera HTML5-Struktur kommer vara för att kunna göra det på ett så tydligt sätt för er som läsare som möjligt såväl som att demonstrera lite varierande kod av hur det kan skrivas :)

Låt oss börja, se nedan:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper"> <!-- Here starts our Wrapper DIV -->
    <header> <!-- Here starts our Header -->
        <section id="logoSection"> <!-- Here starts our Logo Section Wrapper -->
            <h1 id="logo">Logo-text goes here</h1>
            <p id="slogan">This is our Company/Blog Slogan.</p>
        </section> <!-- Here ends our Logo Section Wrapper -->
        <section id="cinfoArea"> <!-- Here starts our contact info area Wrapper -->
            <ul id="cinfo">
                <li><strong>E-mail:</strong> test<span title="exchange -[at]- with @">-[at]-</span>dummy.com</li>
                <li><strong>Skype:</strong> testing_dummy</li>
                <li><strong>City:</strong> TestingTown</li>
            </ul>
        </section> <!-- Here ends our contact info area Wrapper -->
        <div class="clearfix"></div> <!-- Necessary to clear any floats (CSS-positioning) from earlier elements -->
        <nav id="mainMenu"> <!-- Here starts our MainMenu Wrapper in HTML5-Semantic -->
            <ul>
                <li><a href="#">Menyval #1</a></li>
                <li><a href="#">Menyval #2</a></li>
                <li><a href="#">Menyval #3</a></li>
                <li><a href="#">Menyval #4</a></li>
            </ul>
        </nav> <!-- Here ends our MainMenu Wrapper in HTML5-Semantic -->
    </header> <!-- Here ends our Header -->
    <section id="content-wrapper"> <!-- Here starts our Content-Wrapper-Section -->
        
    </section> <!-- Here ends our Content-Wrapper-Section -->
    <footer> <!-- Here starts our Footer -->
        
    </footer> <!-- Here ends our Footer -->
</div> <!-- Here ends our Wrapper DIV -->
</body>
</html>

För mer info om t ex. <strong> och övrigt om HTML5-semantik och hur man på bästa sätt nyttjar och kan använda det för att ge sitt webbinnehåll en starkare och mer betonad betydelse- se: learn.shayhowe.com – HTML5 Semantics.

Som ni ser ovan tog jag mig även friheten att fylla mitt <header>-område med det jag önskar ha där – såsom h1-logo, p-slogan, samt kontaktinfo formaterat i en ul-lista och även våra huvud-menyval som skall hjälpa våra besökare att navigera till sidans undersidor :)

Kontaktinfon är förgylld med HTML5-semantik för ”mini-headlines”/de viktiga delarna, och har även lagt in ett väldigt basic fix för att robotar som crawlar in på sidan inte skall bara kunna sno en e-post adress rakt av och lägga till i kedjebrevs mejl-listor etc. (se <span>-taggen för E-mail). <span>-taggen är väldigt bra för att göra ”inline-justeringar” av innehåll typ som att lägga till tillfälliga inline-CSS-stilar för testing eller annat, eller som ovan lägga till title-text för ett specifikt textstycke, osv.

Fick även lägga in en clearfix innan vår meny börjar då jag tänker flyta ut vår logo till vänstersidan, och vår kontaktinfo-område till högersidan – medan huvudmenyn är tänkt att sträcka sig över hela bredden och Inte flyta någonstans. Då måste man ”återställa”/”resetta” vår float-egenskap som CSS kommer använda sig av för att flyta ut logo och cInfo områdena vid positionering av dessa. Och det görs via ett attribut i CSS kallat ”clear” och man brukar ofta använda denna metodik för utflytnings positionering av HTML-element och därför brukar man ha en klass kallad ”clearfix” som man bara kan lägga på ett <div>-element eller liknande för att återställa allting innan nästföljande element som skall vara utan float kommer – detta måste göras då float-attributet ”smittar av sig” till nästföljande attribut om det inte blir stoppat innan!

Hoppas ni har hyfsat enkelt att följa med än så länge, vet att det kan bli lite rörigt :)

Vidare till nästa moment: vår innehålls del med vänsterspalts <article> och högerspalts <aside> sidospalt:

Steg #5 – Fylla vår innehålls-del av webbsidan

Vi skapar här en <article> för vår vänsterspalt inuti vår content-wrapper-div, såväl som en <aside> (HTML5-Semantisk) sidospalt för vår högerspalt.

Se nedan:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper"> <!-- Here starts our Wrapper DIV -->
    <header> <!-- Here starts our Header-wrapper for Entire Header -->
        <section id="logoSection"> <!-- Here starts our Logo Section Wrapper -->
            <h1 id="logo">Logo-text goes here</h1>
            <p id="slogan">This is our Company Slogan.</p>
        </section> <!-- Here ends our Logo Section Wrapper -->
        <section id="cinfoArea"> <!-- Here starts our contact info area Wrapper -->
            <ul id="cinfo">
                <li><strong>E-mail:</strong> test<span title="exchange -[at]- with @">-[at]-</span>dummy.com</li>
                <li><strong>Skype:</strong> testing_dummy</li>
                <li><strong>City:</strong> TestingTown</li>
            </ul>
        </section> <!-- Here ends our contact info area Wrapper -->
        <div class="clearfix"></div>
        <nav id="mainMenu"> <!-- Here starts our MainMenu Wrapper in HTML5-Semantic -->
            <ul>
                <li><a href="#">Menyval #1</a></li>
                <li><a href="#">Menyval #2</a></li>
                <li><a href="#">Menyval #3</a></li>
                <li><a href="#">Menyval #4</a></li>
            </ul>
        </nav> <!-- Here ends our MainMenu Wrapper in HTML5-Semantic -->
    </header> <!-- Here ends our Header -->
    <section id="content-wrapper"> <!-- Here starts our Content-Wrapper-Section -->
        <section class="leftColumn"> <!-- Here starts our leftColumn Wrapper -->
            <article> <!-- Here starts our Wrapper for article #1 -->
                <h2 class="post-headline">Test Headline-text for Post #1</h2>
                <p class="post-details"><strong>Date:</strong> 2014-09-10 &bull; <strong>Author:</strong> Trekka12</p>
                <p class="post-text">
                    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
                </p>
            </article> <!-- Here ends our Wrapper for article #1 -->

            <article> <!-- Here starts our Wrapper for article #2 -->
                <h2 class="post-headline">Test Headline Text for Post #2</h2>
                <p class="post-details"><strong>Date:</strong> 2014-09-12 &bull; <strong>Author:</strong> Trekka12</p>
                <p class="post-text">
                    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam non orci eleifend dui vehicula cursus. 
                </p>
            </article> <!-- Here ends our Wrapper for article #2 -->
        </section> <!-- Here ends our leftColumn Wrapper -->
        <aside> <!-- Here starts our rightColumn sidebar Wrapper -->
            <h3>Test-headline-text for latest post sidebar "widget"</h3>
            <ul>
               <li><a href="#">post #1 - date: 2014-09-10</a></li>
               <li><a href="#">post #2 - date: 2014-09-12</a></li>
            </ul>
        </aside> <!-- Here ends our rightColumn sidebar Wrapper -->
    </section> <!-- Here ends our Content-Wrapper-Section -->
    <footer> <!-- Here starts our Footer -->
        
    </footer> <!-- Here ends our Footer -->
</div> <!-- Here ends our Wrapper DIV -->
</body>
</html>

Phew det var inte nådigt ;o

Dummytexten ni kan se fåtalet meningar av ovan var genererad från Lipsum.org – Lorem Ipsum generator, som även kan hittas på vår Länkar-sida – väldigt användbart webbverktyg för att fylla ut sina annars tomma hemsidor och prototypsidor.

Blev en hel där när vi nu gjort både en vänsterspalt, såväl som en högerspalt :P

Nu har vi bara den absolut sista delen kvar – nämligen footern/sidfoten:

Steg #6 – Footer med Copyrighttext + 3 st. sektioner för övrigt innehåll

Vi skall här lägga till en paragraf med Copyrighttext i sidfoten av vår sida, såväl som 3 st. sektioner undertill som i framtiden kan hålla länkar, eller övrig data.

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Vår egen första HTML5 webbstandard-validerade Mallsida</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<link href="css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper"> <!-- Here starts our Wrapper DIV -->
    <header> <!-- Here starts our Header-wrapper for Entire Header -->
        <section id="logoSection"> <!-- Here starts our Logo Section Wrapper -->
            <h1 id="logo">Logo-text goes here</h1>
            <p id="slogan">This is our Company Slogan.</p>
        </section> <!-- Here ends our Logo Section Wrapper -->
        <section id="cinfoArea"> <!-- Here starts our contact info area Wrapper -->
            <ul id="cinfo">
                <li><strong>E-mail:</strong> test<span title="exchange -[at]- with @">-[at]-</span>dummy.com</li>
                <li><strong>Skype:</strong> testing_dummy</li>
                <li><strong>City:</strong> TestingTown</li>
            </ul>
        </section> <!-- Here ends our contact info area Wrapper -->
        <div class="clearfix"></div>
        <nav id="mainMenu"> <!-- Here starts our MainMenu Wrapper in HTML5-Semantic -->
            <ul>
                <li><a href="#">Menyval #1</a></li>
                <li><a href="#">Menyval #2</a></li>
                <li><a href="#">Menyval #3</a></li>
                <li><a href="#">Menyval #4</a></li>
            </ul>
        </nav> <!-- Here ends our MainMenu Wrapper in HTML5-Semantic -->
    </header> <!-- Here ends our Header -->
    <section id="content-wrapper"> <!-- Here starts our Content-Wrapper-Section -->
        <section class="leftColumn"> <!-- Here starts our leftColumn Wrapper -->
            <article> <!-- Here starts our Wrapper for article #1 -->
                <h2 class="post-headline">Test Headline-text for Post #1</h2>
                <p class="post-details"><strong>Date:</strong> 2014-09-10 &bull; <strong>Author:</strong> Trekka12</p>
                <p class="post-text">
                    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
                </p>
            </article> <!-- Here ends our Wrapper for article #1 -->

            <article> <!-- Here starts our Wrapper for article #2 -->
                <h2 class="post-headline">Test Headline Text for Post #2</h2>
                <p class="post-details"><strong>Date:</strong> 2014-09-12 &bull; <strong>Author:</strong> Trekka12</p>
                <p class="post-text">
                    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam non orci eleifend dui vehicula cursus. 
                </p>
            </article> <!-- Here ends our Wrapper for article #2 -->
        </section> <!-- Here ends our leftColumn Wrapper -->
        <aside> <!-- Here starts our rightColumn sidebar Wrapper -->
            <h3>Test-headline-text for latest post sidebar "widget"</h3>
            <ul>
               <li><a href="#">post #1 - date: 2014-09-10</a></li>
               <li><a href="#">post #2 - date: 2014-09-12</a></li>
            </ul>
        </aside> <!-- Here ends our rightColumn sidebar Wrapper -->
    </section> <!-- Here ends our Content-Wrapper-Section -->
    <footer> <!-- Here starts our Footer -->
        <p id="copyright-text">&copy; Copyright Year CompanyName. All rights reserved.</p>
        <section id="sectionWrapper"> <!-- Here starts our section-wrapper -->
            <section id="sectionBox1">
            </section>

            <section id="sectionBox2">
            </section>

            <section id="sectionBox3">
            </section>
        </section> <!-- Here ends our section-wrapper -->
    </footer> <!-- Here ends our Footer -->
</div> <!-- Here ends our Wrapper DIV -->
</body>
</html>

Som ni kan se i ovan kod använder jag mig av 2 st. olika HTML-Special characters som är &copy; <- som ger oss det där ©-tecknet, såväl som &bull; som ger mig en fin • <- prick-ikon som man kan använda t ex. som avskiljare ”inline”.

Såja, då tror jag vi nästan är klara med detta inlägget – nu har vi gått igenom steg för steg hur man kan skapa en hel struktur för en HTML5-Webbsida – vad som återstår nu dock för att vara korrekta – är att validera vår sida i W3C HTML5-Validator så vi är säkra på att koden inte är fel på något ställe.

Steg #7 – Validera HTML5-koden så att den följer standarden och inte är felkodad på något ställe!

Vår inklistring av HTML5-koden i W3C HTML5-Validator gav oss följande för ovan webbsida:

W3C HTML5 Validation av webbsida strukturs kod

Dock skriver den att vi fick 9 stycken ”varningar” – dessa brukar vara av typen som man kan strunta i oftast – då man får många varningar om man använt saker som kanske ännu inte fullt ut blivit antaget till HTML5-standarden utan kanske bara är experimentellt, eller om man avviket för hur standarden tänkt att ett element avses att användas – det var detta vi fick varningar för – se nedan:

HTML5 Validation warnings

Dock som ni även kan notera så är alla varningarna för hur vi har använt sections – dock under varningarna står det att vi ändå fått validerat till HTML5, alltså är det inga problem. Och i felmeddelandet kan vi också se att de bara antagit att eftersom vi använde <section> så borde dessa inkludera någon form av underrubriker – men det skulle vi ju inte ha, så allt är lugnt.

Skulle det dock vara som så att ni stör er på dessa ”varningar” så kan ni ersätta våra <section>:s med <div>-element istället.

Steg #8 – Förhandsgranska er sida och se resultatet av ert hårda arbete :)

Som ett litet extra ”treat” så kommer jag visa på hur sidan kan komma att se ut senare med CSS-stilar såväl som hur den ser ut just nu utan några som helst CSS-stilar, för det se nedan:

Första webbsidan förhandsgranskning utan några som helst CSS-stilar

Om vi lägger på ett lager med CSS-stilar hade sidan istället kunna se ut något liknande det ni kan se nedan:

Förhandsgranskning av första sida Med* CSS-Stilar

Det viktigaste verktyget för en webbdesigner och webbutvecklare tror jag är att kunna visualisera sig hur sidan skall se ut innan man börjar bygga den!

Speciellt om du siktar på att bli framgångsrik inom området.

CSS gör skillnad som ni kan se ovan ^^ Väldigt kraftfullt att lära sig för webbutveckling och webbdesign! Ett Måste att lära sig för webbdesign och webbutveckling om du frågar mig :)!

Tidigare i inlägget lovade jag att delge er CSS-stilarna som gjorde ovan HTML-kod till sidan ni kunde se med CSS-stilar nu här på slutet, dessvärre upptäckte jag nyss att dessa stilar förmodligen tappats bort, då jag inte verkar kunna hitta dem någonstans överhuvudtaget. CSS-stilar för hela webbsidor (eller kanske till och med återskapandet av CSS-stilarna för ovan webbplats utseende kan komma att dokumenteras för er att ta del av i framtida inlägg om CSS-kodning).

Slutkläm

I detta inlägg har jag använt mig av många taggar, attribut och attributvärden som vi inte ännu gått igenom, och för den ambitiösa kanske detta kvittar då ni förmodligen redan kollat upp vad allting gör och hur det kan användas, men för alla andra som hade behövt kanske lite extra hjälp att komma in i allting så lovar jag att gå igenom alla saker vi använt oss utav här idag i andra inlägg framöver. Syftet med detta inlägget var ju trots allt att få se en demonstration av processen att skapa en webbsida från scratch, och det tycker jag ändå vi har lyckats täcka med det här inlägget.

Tack för ert tålamod att följa med under hela detta långa inlägg :) Tills nästa gång – experimentera själva och koda på bara ;)

Practice makes perfect.

Hej igen alla läsare :) I detta inlägg hade jag tänkt gå igenom stegen för att skapa vår alldeles första, HTML5-mall (väldigt simplifierad med bara det väsentligaste ”for now” – mer avancerad kommer att gås igenom i ett annat inlägg framöver).

Mallen vi kommer att skapa/visa här kommer ni sen kunna använda som den fundamentalaste grunden som kan utgöra startpunkten för alla era HTML5-webbsidor framöver att utgå från innan man fortsätter vidare till att skapa layout och sådant.

Vi kommer försäkra oss om att mallsidan vi skapar är validerad enligt W3C’s validator för HTML5-standarden, vi kommer även försöka visa på vad de olika delarna på sidan fyller för funktion och varför man bör ha med dem :)

Först och främst, allmänna grunden för webbsida (ej standardenlig, bristfällig, men basic)

<html>
<head>
    <title></title>
</head>
<body>
    this is the bare-minimum of any website OUTSIDE of any standards...
    the <html>-tag to indicate to the browser that it's a web document to be interpreted.
    the <head>-tag that will hold meta-data for the webpage as well as site-title text and load javascripts, css-styles, etc.
    the <body>-tag that holds the entire websites body - that will be visible to the website visitors (with some exceptions in a few cases)...
</body>
</html>

Vänligen OBSERVERA dock att ovan INTE ÄR REKOMMENDERAT att faktiskt koda till ”riktiga webbplatser”. Där saknas några grejer som i kombination med ovan kod, gör webbdokumentet standardenligt utefter den standard man väljer.

Skulle ni besöka W3C HTML Validator verktyg och skriva in ovan kod, så kommer ni få 1 st. ERROR och 4 st. VARNINGAR. (för koden bortsett från texten inuti <body>-taggen)

ERROR-meddelandet som ges kommer se ut såhär:

no document type declaration; implying ”<!DOCTYPE HTML SYSTEM>”

: The checked page did not contain a document type (”DOCTYPE”) declaration. The Validator has tried to validate with a fallback DTD, but this is quite likely to be incorrect and will generate a large number of incorrect error messages. It is highly recommended that you insert the proper DOCTYPE declaration in your document — instructions for doing this are given above — and it is necessary to have this declaration before the page can be declared to be valid.

Ovan felmeddelande talar om att vår mallkod saknade Document Type Definition, vilket innebär att ingen standard för koden man skriver är angiven, vilket också innebär att det är ”fritt fram” för webbläsaren att anta vilken standard man kodar i – och ni kan säkert gissa hur väl/illa det hade kunnat gå om webbläsaren skulle välja fel standard.. :/

Några av VARNINGAR-meddelandena kommer att vara:

1. Unable to Determine Parse Mode!

: The validator can process documents either as XML (for document types such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For this document, the information available was not sufficient to determine the parsing mode unambiguously, because:

  • in Direct Input mode, no MIME Media Type is served to the validator
  • No known Document Type could be detected
  • No XML declaration (e.g <?xml version="1.0"?>) could be found at the beginning of the document.
  • No XML namespace (e.g <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">) could be found at the root of the document.

As a default, the validator is falling back to SGML mode.

Vilket i stort sett betyder att mallkoden vi angav ovan saknade tillräcklig med information för att indikera att det var en webbsida vi kodade. Vilket kan ställa till en del problem när webbläsaren ska försöka tolka koden och presentera element till besökaren för kod som den egentligen inte är helt säker på att den förstår.

2. No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type.

: No DOCTYPE Declaration could be found or recognized in this document. This generally means that the document is not declaring its Document Type at the top. It can also mean that the DOCTYPE declaration contains a spelling error, or that it is not using the correct syntax.

The document was checked using a default ”fallback” Document Type Definition that closely resembles “HTML 4.01 Transitional”.

Learn how to add a doctype to your document from our FAQ.

Verkar praktiskt taget vara samma som vårt första och enda ERROR-meddelande.

3. No Character encoding declared at document level

: No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.

See this tutorial on character encoding for techniques and explanations.

Ovan varningsmeddelande säger i stort sett att inget har angetts för att indikera på vilket språk sidan kodas, eller vilken teckenkodning som skall användas – detta kan i sin tur leda till att t ex. Svenska tecken som Å, Ä och Ö- bokstäverna blir jätteknasiga när de skall presenteras, då webbläsaren inte har den blekaste aning om vilket ”språk” de tillhör/vilken teckenkodning som kan ordentligt presentera tecknen.

Det fjärde varnings-meddelandet var p.g.a. att jag validerade ovan mallkod genom att i stort sett klistra in koden direkt i validatorn, och kan därför ignoreras.

Enda anledningen att jag visar denna grundkod för en HTML-webbsida, är i pedagogiskt syfte att visa på att detta är de allra viktigaste delarna av en webbsida, ett ”bare-minimum” som man kan säga på engelska. Det allra minsta som är nödvändigt för att göra ett webbdokument helt enkelt.

Det är bra kunskaper att ha och det är bra att känna till vilka delar, och i vilken utsträckning man kommer att använda dem. Om ni sen vill kan ni gärna experimentera själva genom att t ex. ta bort <body> taggen, eller kanske <title> taggen från koden och sedan testa klistra in koden i validatorn och köra den igen, se om ni får nya felmeddelande och vad de i sådana fall säger :)

Min rekommendation är att ni bör sträva efter att ha validerad kod för er webbplats, detta försäkrar om att inga onödiga fel riskerar att drabba er i stunden eller längre in i utvecklingsprocessen!

Lite insikt i de olika delarna

Som somliga av er säkert känner till publicerade jag ett inlägg tidigare: Dissekering av webbsida & Genomgång av dess tre fundamentalaste beståndsdelar: DTD, HEAD, BODY , som ger en koncis introduktion till delarna vi har tagit med i vår grundmall ovan. I det inlägget nämner jag även lite snabbt DTD som inte finns med i vår mall ovan, om man vill koda efter en standard (vilket är säkrast och föredraget för bäst- och förutsägbara resultat) så bör man åtminstone känna till att en DTD skall finnas med överst på sidan.

Längre ned i detta inlägg kommer jag även gå igenom en ”korrekt” HTML5 Boilerplate för att ni även ska se och lära er hur det ”korrekta” sättet att bygga basen för en webbsida går till på med dagens senaste moderna webbstandard, HTML5.

Visdomsord innan kodande inleds

Tänk på visdomsorden och rekommendationerna som nämndes och togs upp i inlägget: Bra kodningsprinciper och praktiker för HTML-kodning från XML.

För att vara konsistenta och även demonstrera kunskaperna vi tagit del av bör vi koda vår HTML-mallsida utefter de bra principer och praktiker för HTML-kodning som vi tidigare gått igenom.

Användbar och bra tillgänglig kodmall från andra källor

Innan vi börjar med vår egen mall tänkte jag snabbt nämna att det redan finns en framtagen mall som jag själv brukade utgå från för många av mina tidigare webbsidor, skapad av HTML5Doctor.com och deras kodare, länk till mallen kan hittas på vår Länkar-sida, eller på följande länk: HTML5Doctor.com: html5-boilerplate.

Deras mallsida har det väsentligaste och det nödvändigaste, och den blir dessutom godkänd av W3C HTML5 Validator verktyg för att vara enligt HTML5-Kodstandard(!).

Deras kodmall ser ut som följer:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>HTML 5 complete</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<style>
  article, aside, details, figcaption, figure, footer,header,
  hgroup, menu, nav, section { display: block; }
</style>
</head>
<body>
<p>Hello World</p>
</body>
</html>

Och som ett ”FYI” (For Your Information) inför framtiden angående indentering, så brukar detta vara upp till er som kodar, men för det mesta verkar det populäraste vara att endast börja indentering vid block-element i respektive område (head/body).

Och vad jag då menar med detta är som ni kan se ovan så är det första ”block-elementet” i <head> taggen vårt <style> block där man kan placera On-page CSS-stilmalls kod (mer om detta i inlägg om CSS-kodning senare framöver), där har HTML5Doctor.com valt att indentera, och när det gäller <body> taggen har de endast ett s.k. ”inline-element” (paragraf-taggen (<p>)) som då inte är ett ”block-element” och behöver därför inte indenteras. Men som sagt, detta väljer ni själva hur ni vill göra, men det kan annars vara kul att veta hur man brukar avgöra var det är lämpligt med indentering :)

Genomgång av HTML5Doctors HTML5-boilerplate

Document Type Definition – DTD

Först i HTML5Doctors kodmall kan vi se en DTD för HTML5, som indikerar att standarden koden är skriven utefter, är just det: HTML5.

  <!DOCTYPE html>

HTML & HEAD- taggarna

Därefter följer bastaggarna vi är bekanta med sen tidigare, <html> och <head>.

Meta tagg för teckenkodning

Sen följer en intressant tagg vi tidigare inte sett, nämligen en ”meta tagg” (<meta>), dessa används för att förmedla meta-data för en webbsida, i det här fallet är meta taggen dedikerad till förmedling av teckenkodning (charset för character set). I andra fall kan meta taggar användas för att förmedla sökmotorindexerings nyckelord, sökmotorindexerings sidbeskrivningar, sökmotorindexerings robotregler för sidan (hur sidan skall indexeras), m.m.

Vår charset meta tagg är satt till värdet UTF-8, vilket är en idag väldigt populär teckenkodning, faktum är att det är rekommenderad ”default standard teckenkodning” för HTML-kodning.

Direkt citat från HTML5Doctor’s artikelsida för deras HTML5-Boilerplate säger följande för teckenkodnings meta-taggen:

This final, more complete boilerplate also indicates the character set. Without it, some characters will not render properly.

Mer info om UTF-8 och Unicode teckenkodning

Vid intresse av att läsa mer om UTF-8 som teckenkodning, vänligen se Engelska Wikipedias artiklar om UTF-8 och Informationssida om UTF-8 på webben :) Och för mer information om Unicode som UTF-8 kodar tecknen till, finns följande Engelska Wikipedia sida för Unicode till ert förfogande.

TITLE-tagg

Därefter följer sidans <title> tagg som ni bör ha goda kunskaper om vad den fyller för funktion(er).

HTML5 Shiv och IE-hack för att få HTML5 att funka

Nästa del av boilerplaten är ett Internet Explorer ”hack” för att använda ett script kallat ”HTML5 Shiv” med syfte att få HTML5 att funka i äldre versioner av Internet Explorer (, såväl som Firefox 2 verkar det som), som saknar stöd för standarden.

<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Vad HTML5 Shiv är, och gör

HTML5 Shiv är ett JavaScript fix (kräver alltså JavaScript aktiverat i webbläsaren för att fungera) & script som får äldre ovetande webbläsare att tolka de nya HTML5-elementen korrekt så att man sen kan använda dem och ge dem CSS-stilar utan att det blir oväntade fel och missförstånd när webbläsaren försöker sen översätta och tolka sidan.

Vad detta innebär är att de äldre webbläsarna har inga standard CSS-stilar för hur de nya HTML5-elementen är tänkta att presenteras (alla taggar har ju sina egna egenskaper för hur de fungerar och skall presenteras som webbläsaren får från standarden, saknas standarden dock = brist på standard stilar, egenskaper etc.), vad JavaScript då gör är att gå igenom sidan, identifiera de nya HTML5-elementen, och tilldela dem de nödvändiga egenskaperna (typ CSS-stilar) för att ”verka fungera som de är tänkta”.

Ni kan läsa mer om HTML5 Shiv på: deras GitHub sida: https://github.com/afarkas/html5shiv

Enda nackdelen med HTML5 Shiv är ju som sagt att det finns folk som inte litar på JavaScript och därför har det inaktiverat, då många använde det förr för att göra ”dåliga” saker på webben, vilket oftast lämnade besökare till vissa sidor med en sur eftersmak i munnen, p.g.a. irriterande eller ovälkomna webbupplevelser med reklam, virus, och andra otrevligheter.

ATT TÄNKA PÅ (Visdomsord): Tänk på detta när ni själva designar egna webbupplevelser, vilka besökare det är ni utvecklar webbsidan för, har de JavaScript aktiverat? Använder de gamla webbläsare? Osv. Frågor värda att ställa och ta med i beräkningarna för hur en webbsida skall byggas. Idag finns ännu ett element att överväga, och det är Hur era besökare kommer att besöka er webbsida, kommer de göra det via dator, mobil, surfplatta, eller annat? Vad stödjer den enheten som just dina besökare använder för att visa din webbsida? Behöver du kanske vidta speciella designåtgärder för om de använder pekskärm, eller ej? osv :)

On-page CSS-stilmalls kodblock

Nästa del i HTML5Doctors boilerplate är ett <style> block-element som sträcker sig över flera rader, som håller On-page CSS-stilar, vilket sällan är rekommenderat – speciellt om man har många undersidor, men anledningen till deras användning i det här fallet, är då deras mall enbart är tänkt att utgöras av 1 enstaka fil! Och då är det okej :) Annars vid större webbprojekt bör man överväga att placera denne CSS-kod i ett extern CSS-kods dokument, men mer om detta senare när vi börjar gå igenom CSS-kodning.

CSS-koden som HTML5Doctor har angivet i detta On-page CSS-blockelement är kod för att informera (även här) ovetandes webbläsare om hur block-level element skall presenteras genom att lista alla elementen och tilldela alla elementen en och samma stil, nämligen display as block.

Slutligen body och stängning av öppnade taggar

Sedan följer det gamla vanliga som ni kan se, <head> taggen stängs, innan <body> taggen öppnas och stängs, för att representera webbsidans ”kropp” som sen kommer bli presenterad för besökarna.

Slutkläm & presentation av framtida inplanerat inlägg

Det är inget fel med att använda någon annans kodmall, speciellt inte när den är så välgjord som den vi gick igenom ovan. Personligen är det min favorit kodmall att utgå från (eller brukade vara åtminstone), dock så har jag numera vidareutvecklat den en aning för mina egna sidor jag brukar bygga, dels har jag piffat upp den med PHP som förebyggande för att ha multipla undersidor med samma mallkod – för att undvika att behöva ändra på varje enstaka undersida bara för att alla har samma sidhuvud/sidfot, t ex. Med hjälp av PHP dynamisk konstruktion av kodmallen så används en och samma sidhuvud, respektive sidfot till samtliga sidor.

Jag inkluderar även för mina egna sidor:

  • Externt stylesheet (CSS-stilmall för samtlig CSS koder),
  • ibland en CSS ”printstyles” alternativ extern stilmall (för utskrifts stilar för sidor – inte ofta dock),
  • meta-taggar för On-page sökmotoroptimering,
  • favicon inkludering,
  • ibland eget visitor-tracking PHP-script,
  • Google Analytics i botten av sidan,
  • jQuery kod såväl som JavaScript filer (om det används för sidan),
  • LESS CSS preprocessor kod om jag använder det för CSS-kodningen (inte ofta),
  • Eric Meyers CSS-Reset v.20 för HTML5-reset,
  • Ibland Modernizr för HTML5/CSS3 feature detection (JavaScript bibliotek som hjälper till att upptäcka stöd för HTML5 och CSS3 funktioner hos besökaren, så man då kan vidta åtgärder baserat på om stöd skulle saknas, eller ej)
  • Google Fonts för typografiskt teckensnitt stöd och-
  • ibland övriga JavaScript filer.

Såja! Då har vi gått igenom HTML5-kodmall ordentligt i det här inlägget.

Låna gärna av ovan presenterade mallkod, experimentera på egen hand, lägg till, ta bort, och jämför vad som händer och se vad som blir annorlunda vid validering av koden.

Tills nästa gång ;)