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

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

Introduktion – Vad är Responsiv Webbdesign?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Breaking-points kodningsmetoden

Att tänka på

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

Nackdelar?

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

Fördelar jämfört med Enhetsspecifika kodningsmetoden

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

Hur kodningsmässigt?

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

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

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

Enhetsspecifika kodningsmetoden

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

Nackdelar?

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

Fördelar?

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

Hur kodningsmässigt?

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

Verklighetsbaserat exempel

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

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

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

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

Toggle Device Mode aka Responsive testing environment

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

rwd mode gchrome

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

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

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

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

firefox rwd mode

 

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

Cloudbased Browser & Device- compatibility testing online

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

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

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

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

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

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

CSS Media Queries & Responsiv webbdesigns-specifik kod

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

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

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

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

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

CSS Media Query basics (grunder)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • none
  • hidden

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

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

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

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

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

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

Touch-baserade features för responsiva webbsidor

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

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

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

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

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

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

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

Handpositionering för smartphones och surfplattor

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

Exempel Responsiv Webbdesigns kod- och Effekt i praktiken

test1

test2

test3

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

Step 1: File structure

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I detta inlägg tänkte jag gå igenom Block-level element behållare som vi har till vårt förfogande i HTML(5). Vi ska gå igenom följande element, hur man kan använda dem, såväl som vilken funktion de är tänkta att fylla:

Element Beskrivning och funktion Länk
<div> Division element för icke-semantisk behållare, se MDN citat nedan:

The HTML <div> element (or HTML Document Division Element) is the generic container for flow content, which does not inherently represent anything. It can be used to group elements for styling purposes (using the class or id attributes), or because they share attribute values. It should be used only when no other semantic element (such as <article> or <nav>) is appropriate(!).

MDN Referenssida
<section> Sektions/avdelnings- element, semantisk behållare för att märka upp tematiska delar av en webbsida. Se MDN citat nedan:

The HTML Section Element (<section>) represents a generic section of a document, i.e., a thematic grouping of content, typically with a heading. Each <section> should be identified, typically by including a heading (<h1><h6> element) as a child of the <section> element.

MDN Referenssida
<article> Artikel element, semantisk behållare för användning vid artikelliknande webbinnehåll, se nedan MDN citat:

The HTML Article Element (<article>) represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable, e.g., in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, or any other independent item of content. Each <article> should be identified, typically by including a heading (h1h6 element) as a child of the <article> element.

MDN Referenssida
<footer> Sidfots element, semantisk behållare tänkt att användas för att definiera en webbsidas sidfot! MDN Referenssida
<header> Sidhuvud element, semantisk behållare, motsvarighet till <footer> fast tänkt att användas för att definiera en webbsidas sidhuvud. MDN Referenssida
<aside> Sidospalts element, semantisk behållare tänkt att definiera sidospalter för webbsidor. MDN citat nedan:

The HTML <aside> element represents a section of the page with content connected tangentially to the rest, which could be considered separate from that content.

MDN Referenssida
<pre> För/O-formaterat element, tänkt att användas när webbläsaren inte ska tolka texten i behållaren. Se MDN citat nedan:

The HTML Preformatted Text (<pre>) represents preformatted text. Text within this element is typically displayed in a non-proportional font exactly as it is laid out in the file. Whitespaces inside this element are displayed as typed.

MDN Referenssida
<nav> Navigations element, tänkt att användas för navigations menyer och liknande för webbsidor. Se MDN beskrivning nedan:

The HTML Navigation Element (<nav>) represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

MDN Referenssida

För att se bra praktiska exempel på när många av dessa elementen t ex. kan användas, så ta en titt på tidigare inlägg där vi gick igenom visualisation och realisation av layout för en webbsida.

Annars tycker jag inte där finns mycket mer att säga om dessa 🙂

När man använder <pre> elementet för “preformatted” text

<pre> elementet är ett bra element som jag inte gick igenom i ovan länkade tidigare inlägg, som är väldigt användbart om man vill presentera kod på en webbsida i block-form.

Detta inlägg har som syfte att gå igenom alla användbara och viktiga taggar att känna till för att strukturera upp själva innehållet för en webbsida. Därför kommer jag i det här inlägget gå igenom följande taggar:

  • <hX> (för rubriktexter),
  • <hgroup> (för rubriktexts gruppering),
  • <p> (för paragrafer),
  • <strong> & <b> (för fetstil),
  • <em> & <i> (för kursiv stil),
  • <u> (för semantiskt understruket för t ex. betydelsen: felstavning)
  • <sup> (för upphöjt med),
  • <sub> (för nedsänkt),
  • <br /> (för radbrytning),
  • <hr /> (för sektionsavdelare),
  • <code> & <pre> (för inline- och block-kod),
  • <blockquote> & <cite> & <q> (för citat av olika slag),
  • <span> (för inline-container alternativ till <div>),
  • <mark> (för text-highlightning) samt
  • <a> (för länkar).

Dessa element är väldigt populära och användbara för semantisk uppmärkning av ens webbsidas innehåll, såväl som strukturering av webbsidans innehåll för lättläslighet och professionellare känsla. Dock är inte ovan listade element de enda som finns, learn.shayhowe.com går igenom några andra som finns, och ni kan säkert hitta ytterligare fler på andra webbsidor, men jag har valt att gå igenom dessa då jag tror dessa är några av de populäraste, och de som ni kommer att använda mest för era webbsidor.

Rubriker (och rubrikgruppering (“experimentell teknologi”)) (<hX> & <hgroup>)

Rubriktexter är något väldigt användbart att känna till när man ska ha hand om innehåll för webben. Där finns ett antal “olika” <hX> taggar (därav X:et), de olika alternativen som finns kan ses nedan:

  1. <h1> – Första rubriktexten (störst sökmotorindexerings vikt, såväl som första hierarkiska rubriktext)
  2. <h2> – Efterföljande underrubrik till <h1> (andra rubriktext i hierarkisk ordning)
  3. <h3> – Efterföljande underrubrik till <h2> (tredje rubriktext i hierarkisk ordning)
  4. <h4> – Efterföljande underrubrik till <h3> (fjärde rubriktext i hierarkisk ordning)
  5. <h5> – Efterföljande underrubrik till <h4> (femte rubriktext i hierarkisk ordning)
  6. <h6> – Efterföljande underrubrik till <h5> (sjätte rubriktext i hierarkisk ordning)

När man strukturerar upp textinnehåll för webben så anger man <h1> som “huvud-rubrik”/första rubrik för en webbsida eller en del av webbsidans innehåll, därefter följer <h2> som underrubrik till det innehållet som <h1> började presentera.

Det är lite svårt att förklara med ord såhär via text, men om ni tänker er att ni har ett blogginlägg om detta här som ni just nu läser, så var min <h1> rubriktext (första rubriktexten)- den stora ni såg överst innan själva inlägget började: “HTML Text & “Inline” taggar – Radbrytning (&lt;br&gt;)…“.

Därefter kom <h2> taggar inuti inlägget för att dela upp inlägget i olika under-delar som t ex: “Rubriker (och rubrikgruppering) (<hgroup> & <hX>)” <- det är en <h2> rubrik, underrubrik till vår <h1> rubrik.

Sedan längre ned kommer ni se en <h3> tagg som ytterligare delar upp <h2> området i sina egna under-områden där vi kommer skriva <hgroup> för att specifikt kunna gå igenom det elementet i det <h3> området.

Ursäktar att det är lite rörigt att beskriva, men jag hoppas ni ändå kan förstå hur jag menar 🙂

<h1> taggar är även de rubriker som “väger mest” vid sökmotorindexeringen – så se till att ha bra texter i dessa! 😉

MDN’s referenssida för <hX> taggar skriver detta som beskrivning för taggarna:

Heading elements implement six levels of document headings, <h1> is the most important and <h6> is the least. A heading element briefly describes the topic of the section it introduces.

<hgroup> för gruppering av rubriktexter

Om där skulle komma ett tillfälle då ni finner er ha att t ex. där först finns en <h1> rubrik, direkt följt av en <h2> (och eventuellt en <h3> rubrik) exempelvis, så kan man semantiskt “gruppera” dessa genom att omsluta dem med ett <hgroup> element för att indikera att det är en rubrikgrupp.

Notera dock(!) att detta är enligt MDN’s referenssida för hgroup – en “experimentell teknologi”, vilket innebär att alla webbläsare ännu kanske inte har stöd för detta element!

MDN’s referenssida skriver även följande för en bra beskrivning av det tänkta syftet av <hgroup>:

It allows associating secondary titles, like subheadings, alternative titles, or even taglines, with the main heading, without polluting the outline of the document.

Paragrafer för textstycken (<p>)

Efter att vi lagt in våra rubriker för innehållet är det dags att semantiskt märka upp våra textstycken, så att vi kan lägga in innehållet för rubriktexterna. Detta gör vi med hjälp av våra <p> taggar för att representera paragrafer på webbsidor.

“Inkorrekt användning” av <p> taggen

Ett vanligt misstag jag tror många nybörjare gör som inte ofta tas upp, utan snarare kanske antas höra till “sunt förnuft” är att inte ha endast en paragraf till hela textinnehållet som skall höra till en rubriktext. Många gör på det viset, och använder sig av radbrytningstaggar (<br />) för att strukturera upp sitt textinnehåll på webbsidor. Se nedan exempel:

 

Visuellt "måhända korrekt", men fortfarande väldigt dåligt och felaktigt* kodade paragrafer.

Visuellt “måhända korrekt”, men fortfarande väldigt dåligt och felaktigt* kodade paragrafer.

Man kan säga att radbrytningarna “lurar” dig till att tycka det är korrekt, men tar du bort de ser du att det inte ser rätt ut alls. Man ska kunna se att det är olika paragrafer utan radbrytningar!

Detta är inte hur <p> taggen var tänkt att användas. Självfallet kan man lägga in radbrytningstaggar inuti sina <p> taggar, men om man behöver lägga in fler än 2/3 st. radbrytningar direkt efter varandra för att indikera “nytt stycke”, så är det lika bra att stänga <p> taggen istället och “avsluta stycket” där, för att sedan för efterföljande text skapa ett helt nytt <p></p> spann för den texten! Se nedan korrekt exempel:

“Korrekt användning” av <p> taggen

Ordentlig representation av paragrafer via HTML koden!

Ordentlig representation av paragrafer via HTML koden!

Skönheten med <p> taggar stilmässigt (förutom att du får enorm frihet via CSS) är att webbläsare tilldelar oftast en “standard-botten-marginal” till alla <p> taggarna, vilket gör att radbrytningstaggar är helt överflödigt när det gäller för att “visa på” ett nytt stycke. Detta görs alltså automatiskt tack vare dessa standard stilar, som ni även kan se i ovan bild 🙂

Undantaget med radbrytningar inuti paragrafer

Det är OK att använda radbrytningar inuti paragrafer, så länge de används tillhörande ett stycke på korrekt vis, vissa stycken behöver bredas ut över mer än 1 enstaka sammanhängande text, då är detta OK, men detta måste ni känna efter själva vilket som är lämpligast 🙂

Fetstil med/utan semantisk innebörd (<strong> & <b>)

Detta gick vi igenom i föregående inlägg för semantisk HTML kodning för sökmotorindexering där vi visade hur learn.shayhowe.com visade på skillnaderna, och nämnde att <strong> var till för att indikera saker med “strong importance” (väldigt viktigt), medan <b> var mer åt “stylistically offset” (stilistisk fetstil) hållet.

Så försök tänka vilket som passar i just er situation, vilket som är lämpligast, och kör sen på det 🙂

Kursiv stil med/utan semantisk innebörd (<em> & <i>)

Även detta var en del som gick igenom i föregående inlägg för semantisk HTML kodning för sökmotorindexering där vi även här hänvisade till learn.shayhowe.com’s sida som beskrev <em> som “stressed emphasis” (“stressad” betoning), medan <i> mer var “alternative tone/voice” (alternativ klang i texten).

Även här- försök ha detta i åtanke när ni ska välja vilket som är lämpligast att använda för just er situation 🙂

Semantiskt understruket (<u>) och icke-semantiskt alternativ (<span> med CSS)

Inte förrän nyligen var det som jag förstod vad <u> egentligen är tänkt att användas för, och insåg att jag tidigare hade använt den med fel avsikt då jag antog att det var “meningslöst semantisk understreck – endast visuellt”, fast så verkar ju inte fallet vara efter att ha läst på MDN’s referenssida för <u> taggen.

Tydligen var <u> borttagen från både XHTML såväl som HTML 4.01, men återintroducerad vid HTML5 med följande innebörd:

In HTML5, this element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelled.

Vilket typ innebär att såvida man inte skriver kinesiska, så är det vid felstavningar och liknande det är lämpligt att användas.

MDN’s referenssida rekommenderar även att man undviker användning av <u> där dess understrukna visuella utseende kan förvirras med länkar.

Icke-semantiskt alternativ för understruket med <span> & CSS

Om ni bara vill ha visuellt understruket, och inte nödvändigtvis ha någon specifik innebörd med er understrykning, så är det <span> taggen tillsammans med en klass eller ID, för att sedan via CSS ange ett attribut för att ge er <span> tagg det visuella understrukna utseendet (Mer om detta kommer senare gås igenom i inlägg om CSS-kodning).

Upphöjt med- och nedsänkt text (<sup> & <sub>)

Har ni någon gång funnit er i en situation där det hade varit behjälpligt att kunna göra som i t ex. Microsoft Office Word- där man kan “nedsänka”, respektive “upphöja” bokstäver/tecken/siffror för webbsidas innehåll? <sup> och <sub> finns tillgängliga för att hjälpa till med detta.

Praktiska exempel för när <sup> skulle kunna vara användbart är t ex. om ni skriver något textinnehåll där det förekommer area-måttenheter (m2) eller volym-måttenheter (m3) och liknande. Medan praktiskt exempel för <sub> istället hade kunnat vara om ni skriver kemiska beteckningar och hade behövt en korrekt presentation som t ex: H2O för vatten.

Båda dessa exemplen kodas på följande vis:

Kan vara användbart att känna till 😉

Radbrytning och sektionsindelning (<br /> & <hr />)

Behöver ni göra radbrytningar har ni alltid <br /> till ert förfogande för att få jobbet gjort 🙂 1 st. radbrytning går ned till nästföljande nya rad, medan 2 st. på varandra följande radbrytningar går ned 2 st. nya rader, vilket får det att presenteras som 1 rads mellanrum mellan innehållet före radbrytningarna, och efter radbrytningarna.

För MDN’s referenssidas beskrivning av <hr /> taggens syfte och funktion se nedan citat:

The HTML <hr> element represents a thematic break between paragraph-level elements (for example, a change of scene in a story, or a shift of topic with a section). In previous versions of HTML, it represented a horizontal rule. It may still be displayed as a horizontal rule in visual browsers, but is now defined in semantic terms, rather than presentational terms.

Visning av kod på webbsidor inline och i block (<code> & <pre>)

När ni vill markera kodsnuttar inuti texter (inline) så används <code>, medan:

…istället används för att presentera kod-stycken i “blockform”.

Presentation av olika typer av citat på ens webbsida (<blockquote> & <cite> & <q>)

När jag gör citat så låter jag WordPress göra grovjobbet åt mig – även om det inte alltid är 100% semantiskt korrekt (tyvärr), därav har jag inte så mycket erfarenhet med dessa element, men anser ändå att det är värdefullt att ha kännedom om dem och känna till hur man använder dem, såväl som när.

learn.shayhowe.com skriver följande beskrivning om när vilket element bör användas, som jag själv anser beskriver det väldigt bra 🙂

  • <cite>: Used to reference a creative work, author, or resource
  • <q>: Used for short, inline quotations
  • <blockquote>: Used for longer external quotations

Kodexempel för respektives användning kommer nedan – citerat/inspirerat från learn.shayhowe.com:

<cite> för citering av kreativa verk

The <cite> inline element is used in HTML to specifically cite a creative work; the element must include either the title of the work, the author’s name, or a URL reference to the work.

<q> för dialog citering

The <q> element semantically indicates quoted dialogue or prose and shouldn’t be used for any other purposes.

By default, the browser will insert the proper quotation marks for us.

<blockquote> för flerrads citering från extern källa

To quote a large block of text that comes from an external source and spans several lines, we’ll use the <blockquote> element. The <blockquote> is a block-level element that may have other block-level elements nested inside it, including headings and paragraphs.

The cite attribute can be included on the <blockquote> element—in the same way that it was used on the <q> element earlier—to provide a citation reference to the quote in the form of a URL.

Inline-container för markering av specifika text-delar (<span>)

<span> elementet är väldigt användbart när ni vill tilldela CSS-stilar eller liknande till specifika delar av en text – detta görs då genom att omfamna ert specifika område med text ni önskar styla med <span> & </span>, se exempel nedan:

Som ni även kan se i ovan exempel på har jag angivit ett class attribut för <span> elementet, klass eller ID måste vi ange om vi vill kunna “sikta” våra CSS-stilar till just det specifika <span> området i texten.

Highlightning av text (<mark>)

<mark> är ett element jag nyligen snubblade över, som kan vara användbart för referensindikering av speciella ord i en text, eller för att “highlighta” söktermer i sökresultat.

Se MDN’s referenssida för <mark> och deras beskrivning nedan:

The HTML Mark Element (<mark>) represents highlighted text, i.e., a run of text marked for reference purpose, due to its relevance in a particular context. For example it can be used in a page showing search results to highlight every instance of the searched-for word.

Länkar på webbsidan (<a>)

Länkar har vi tidigare gått igenom, jag hänvisar er här till föregående inlägg om HTML’s länktagg <a>.