5. Moment05 - Teori

Även om denna kurs till största delen är väldigt praktisk med skapande så måste vi också lära, och förhålla, oss till viss teori. Vi kommer i detta moment kika på internets utveckling fram tills idag, du skall få fundera på internets påverkan på samhället och vi skall lära oss de lagar som vi behöver förhålla oss till när vi utvecklar applikationer till webben.

5.1 Momentets mål

I varje moment så jobbar vi mot ett eller flera mål som skolverket har satt upp i varje kurs.

5.1.1 Centralt innehåll

• Webben som plattform, dess historia och samhällspåverkan.
• Processen för ett webbutvecklingsprojekt med målsättningar, planering, specifikation av struktur och design, kodning, optimering, testning, dokumentation och uppföljning.
• Riktlinjer för god praxis inom webbutveckling.
• Interoperabilitet genom att följa standarder och testa på olika användaragenter.
• Applikationer som fungerar oberoende av val av användaragent, operativsystem eller hårdvaruplattform och hur tillgänglighet uppnås även för användare med funktionsnedsättning.
• Kvalitetssäkring av applikationens funktion och validering av kodens kvalitet.
• Terminologi inom området webbutveckling.

5.2 Internets historia

Vi skall gå igenom webbens historia och för detta använder vi oss av informationen på den utmärkta svenska webbplatsen internetmuseum.se. När internetmuseum öppnade så skapade de en tidslinje över internets historia från den första av en mängd artiklar om det intergalaktiska nätverket hela vägen fram till den senaste artikeln (januari 2025) om att Elon Musk köper Twitter. Varje artikel belyser ett visst ämne, fenomen eller händelse som har påverkat internets utveckling. Många artiklar innehåller fantastiska filmer om hur det var, och några av de saker som forskare och användare förutspådde har slagit in eller inte alls varit i närheten av att slå in. Vi får ha respekt att internets utveckling har gått enormt snabbt, framförallt hur det används på senare år, vilket gör att vi hela tiden måste lära oss att tänka om och tänka nytt. I början av 2000-talet tyckte de flesta att det var helt onödigt att ha en kamera i telefonen, våra krav ser lite annorlunda ut idag. På Internetmuseum finns det också en kortare sammanfattning av det viktigaste om internets historia. Vilken påverkan hade IT-undret i slutet av 1990-talet på internets utveckling och digitalisering? Det finns en film som är nästan en timme lång men som är klart sevärd, IT-bubblan som aldrig sprack.

Under våren 2022 så började internetmuseum publicera guidade turer som är inspelade avsnitt med olika fokus.

En annan historiebeskrivning är att leta upp historiken kring en specifik webbsida. Det kan du göra genom tjänsten archive.org. Det kan ju vara intressant att se hur en webbsida har utvecklats över tid, kanske din egen, kanske den sidan som är din favorit idag eller så finns det ju möjlighet att ta fram en nyhetstjänst en viss dag för att se hur nyheterna presenterades då.

5.3 Kvalitetssäkring av webbsidans funktion och kodens kvalitet

Vi har flera gånger pratat om vilken hjälp vi får av webbläsare som tolkar koden åt oss ifall vi skriver inkorrekt kod, det finns både för- och nackdelar med detta. Fördelen är att sidan visas i webbläsaren medan nackdelarna kan vara flera, dels så kanske sidan visas upp på ett annat sätt än vad vi vill eftersom den tvingas tolka den kod som inte är korrekt. Även om sidan visas korrekt i en webbläsare så är det ingen garanti att den tolkas på samma sätt i en annan webbläsare. Därför är det så viktigt att testa dina applikationer i flera webbläsare, eller användaragenter som det också kallas.

Här är det också på sin plats att höja en liten varning för inbyggda servrar i de IDE som ni använder. De har absolut sin funktion och nytta men denna server kan redan innan webbläsaren gör en tolkning av din sida förändra de fel som du eventuellt har skrivit. När du sedan lägger upp sidorna på ditt webbhotell så blir du inte räddad av detta och då fungerar inte din site som det är tänkt. Vanliga problem som de inbyggda servrarna tolkar till din fördel är felaktiga länkar (mappar och undermappar som inte har den strukturen som du hade tänkt) eller problem med versaler/gemener i filnamn.

I detta avsnitt så skall vi gå igenom en mängd tester och kontroller som behöver genomföras för att vara säker på att webbsidan håller bra kvalitet.

5.3.1 Validering av kod

I denna kurs så jobbar vi med de två grundteknikerna HTML5 och CSS. Eftersom vi inte naturligt får någon hjälp i webbläsaren med validering av dessa tekniker så måste vi göra det själva.

5.3.1.1 HTML5

validator.w3.org är en bra valideringstjänst för din HTML5-kod. På sidan kan du välja att klistra in kod (vilket är smidigt när du utvecklar sidan lokalt på din dator), ladda upp en fil eller skriva in en länk till en sida som ligger på en webbserver uppkopplad till internet. När du sedan klickar på check så valideras kod och ger dig information om saker som är direkt felaktiga, som bör ändras eller som kan ändras. Valideringen sker mot standarden men ibland kan det finnas anledning att inte följa standard. Ju duktigare du blir på både kodning och felsökning desto bättre beslut kan du ta om vad som behöver ändras.

En funktionalitet som jag använde mig av på en tidigare version av kursolle var att i sidfoten ha en länk till denna validering, i den nuvarande versionen har jag ingen sidfot och då har jag också tagit bort dessa länkar. Men så här såg länken ut, https://validator.w3.org/nu/?doc=http://www.kursolle.se/weuweb01/moment05.php. Det är ju inget som skall användas på en sida som levereras till kund men kan vara smidigt att använda i test och utvecklingssyfte.

5.3.1.2 CSS

jigsaw.w3.org/css-validator är en tjänst från samma organisation, W3, som ovan och den funkar på i stort sett samma sätt fast nu valideras CSS. Du skall för så bra kod som möjligt göra så få avvikelser från standard som möjligt och det kan vara skönt att få koll på saker som är obsolete vilket innebär att det är attribut som inte längre används och snart inte finns stöd för. Länken till denna sidans validering.

Men är det ok att inte rätta de fel som validatorerna ger? I normalfallet så vill jag ju att du använder validatorerna som en hjälp att skriva bra och effektiv kod. Genom att lära sig reglerna så förstår man och vilka regler man kan bryta mot/avvika ifrån och när detta kan göras. Att använda kod från andra tjänster innebär ibland att vi får acceptera fel. Att försöka hänvisa till fel och hitta på en anledning till att inte rätta dessa fel är fel sätt att ta sig an utmaningen.

Typiska varningar som ni kommer stöta på när ni valderar HTML-kod är att validatorn klagar på att ni inte använder rubriker i vissa element som t.ex. section och article. Orsaken till detta är att enligt HTML5-standarden så skall dessa element direkt innehålla en rubrik. Så hur löser vi det?

1. Vi lägger in en rubrik som vi egentligen inte vill ha.
2. Vi lägger in en rubrik som vi sedan väljer att inte visa mha css-instruktioner som t.ex. visibility: hidden.
3. Vi byter ut alla element som ger oss problem mot div-element och väljer att inte följa HTML5-standarden.

Vilken av lösningarna gör oss nöjda? Ingen av dem så vi låter varningen vara men vi kommenterar varför vi låter den vara i vår utvärdering och validering av våra projekt.

5.3.2 Användaragenter

Användaragenter innebär i vår värld olika webbläsare i en dator men också webbläsare i smartphones och tablets. För att göra ett fullständigt test i varje användaragent så behöver du testa i alla webbläsare och i alla typer av smartphones/tablets men det är ju orimligt för våra applikationer. Jag kommer dock kräva att du alltid testar på minst två olika webbläsare där den ena skall vara Google Chrome som är den som flest sidvisningar görs i, och sedan en webbläsare till, förslagsvis Mozilla Firefox då många av de som bestämmer standarden för html/css arbetar inom Mozillas organisation.

Safari och Edge är också många som använder och en stor anledning till detta är att det är standardwebläsare i Apples produkter samt Microsoft Windows. Så gör du inget aktivt val så är det dessa webbläsare som du får. Tyvärr så har bägge dessa företagen rent historiskt hittat på lite egna lösningar vilket gör dem problematiska att testa i.

De stora webbläsarna har idag alla någon form av utvecklarläge där det finns ett antal hjälpverktyg för webbutvecklare. Dessa verktyg behöver du lära dig att dra nytta av. När du ändå håller på kika om du kan hitta läget där du kan se hur din landing page ser ut i en smartphone eller en tablet. I nästa moment kommer vi lära oss bygga webbsidor som är mer anpassade för olika användaragenter.

När du kollar hur din webbsida ser ut i ett mobilläge från utvecklarverktyget så kanske du tycker att den ser väldigt bra ut och är synnerligen mobilanpassad men är det verkligen så? För att testa detta så använder vi oss av verktyg för att få en objektiv bedömning. Google hade ett verktyg som på ett tydligt sätt kunde göra en enklare bedömning om webbsidan ansågs mobilvänlig eller inte. Tyvärr så stängdes denna ner 1 december 2023 och de flesta verktyg är anpassade för mer avancerade webbutvecklare och innehåller en hel mängd tester, vi kommer kika på dessa tester lite senare i detta momentet. Jag har hittat en ny tjänst som verkar vettig för ändamålet, vilket är att göra en enklare bedömning av en webbsidas mobilvänlighet. Bing har ett Testverktyg för mobilvänlighet som vi testar lite och utvärderar tillsammans.

5.3.3 Prestanda

En sak som är viktig när vi bygger våra webbsidor är att skapa förutsättningar för att vi skall ha så kort laddtid på våra sidor som möjligt. En viktig del är att skriva korrekt kod, html och css, vilket vi kontrollerat genom att validera koden. Men det finns fler sätt att optimera våra sidor och det skall vi kolla på i detta avsnitt.

Det finns flera användbara tjänster på nätet som gör analysen av vår sida och även ger oss bra tips på hur sidan skall förbättras. I denna kursen så fokuserar vi på de stora justeringarna för att förbättra våra webbsidor och webbplatser, det är lätt att fastna även i smådetaljer och jaga millisekunder men det är inte fokus för oss utan mer för de som jobbar med detta professionellt. Det är ändå kul att vi till viss del använder samma verktyg, men det innebär också att vissa råd kräver en högre kunskapsnivå än vad vi lär oss i denna kursen. Jag kommer länka till tre olika verktyg som alla är bra och som testar lite olika saker och ger råd på lite olika sätt. För att du skall känna vilken du tycker passar dig bäst så vill jag att du testar alla tre verktyg iaf en gång var. När du sedan testar dina webbsidor så handlar det ju hela tiden om att du skall få den bästa hjälpen för att göra bra förändringar som gör dina sidor snabbare.

• Google PageSpeed Insights, denna ger dig förklaringar och tips på svenska så börja gärna med den. PageSpeed Insights bygger på Lighthouse vilket är Googles verktyg och Lighthouse går också att använda via Inspekteraren i Google Chrome, här finns en instruktion på YouTube.
• Webpagetest, gör flera analyser på samma gång och betygsätter din sida på flera olika områden vilket gör det enklare att avgöra prioritetsordningen för vad som skall åtgärdas. Ger dig också en bra förståelse för vad som eventuellt bromsar upp en sida då du tydligt ser i vilken ordning olika saker sker.
• Pingdom, överskådlig men ej så detaljerad. Den talar om vilka prestandaproblem som finns generellt men inte exakt var dessa finns. Länken är ändå med eftersom Pingdom ofta används och hänvisas till när det pratas om prestanda.

Alla fyra tjänsterna analyserar din sida och ger olika riktvärden för vilken prestanda en webbsida har och ger sedan tips på hur du kan förbättra denna. Nu kommer du märka att detta är verktyg som även används av professionella webbutvecklare. Här kommer du kunna få tips att ta bort kod som inte används, tex css och javascript, minifiera koder, välja andra bildformat, komprimera bilder och också komprimera text och kod (vilket ligger utanför denna kursen). Här gäller det att se vad som kan åtgärdas av oss för tillfället.

Det enklaste vi kan göra i denna kursen är att skriva kompakt kod, ta bort onödiga mellanslag och mängder av luft vilket gör att det går fortare att hantera filen och skicka den till användaren. Här pratar vi om korta tider men om vi kapar tid i varje led så finns det faktiskt en hel del tid att vinna. Vilka verktyg kan vara intressanta att använda här?

• dirtymarkup.com används för att snygga till kod i html/css/javascript vilket gör koden lättare att läsa men den tar också bort onödig luft. Skriver du extremt tight kod så kan en körning i detta verktyg göra att det tillförs luft.
• Compress HTML kan användas ifall du vill ta bort alla white spaces i din html-kod.
• csscompressor.com tar bort mycket, eller all luft i ett css-dokument. Hur mycket du vill ta bort handlar om vilken läsbarhet som du vill ha. I ett färdigt projekt där det finns många eller stora css-filer så kan det vara värt att låta verktyget ta bort all luft och göra det så litet, och oläsligt som möjligt, för att optimera hastigheten. Senare i kursen så kommer du stöta på filer som har namn som style.min.css och dessa är oftast maximalt komprimerade. Verktyget kan också göra en decompress så att koden blir lättare att läsa.
  Andra verktyg som gör liknande saker htmlcompressor.com, jscompress.com, miniwebtool.com/html-compressor. Det finns fler på nätet, hitta din favorit.

5.3.4 Bildformat

När du har gjort prestandatester på dina webbsidor så återkommer hela tiden olika kommentarer om bilder och hur detta påverkar sidans prestanda. Då är det väl dags att vi kikar även på detta.

Vi kikar på några olika sätt att fixa till bilderna så att de blir mer anpassade för vår webbsida. Det finns flera olika tekniker att använda oss av, ibland räcker en av teknikerna och ibland får vi använda flera.

5.3.4.1 Bilder i rätt storlek

En bild som du publicerar på en webbsida bör visas upp i den storlek som bilden har. Om du väljer att skala ner en stor bild till ett mindre format på webbsidan så får du två problem när det gäller prestanda.

1. En större bild, som innehåller fler pixlar, tar mer utrymme och kommer då också behöva mer bandbredd för att skickas till användaragenten där den skall visas upp.
2. En bild som inte är i rätt storlek måste förminskas, eller förstoras, i webbläsaren vilket tar onödig tid.

Enklast är att skapa filen i rätt storlek från början i något bildredigeringsprogram men det finns också tjänster online för detta t.ex. imageresizer.com och picresize.com.

5.3.4.2 Optimera bilder

Det finns flera olika bildformat som kan användas på webben. De klassiska formaten är JPEG/PNG/GIF/SVG. PNG och JPEG lämpar sig bäst för bilder, GIF lämpar sig för enklare bilder som logotyper och SVG är vektorbaserad vilket gör att den är knivskarp även om man zoomar in den bilden.

Om du använder bilder som finns på nätet så är du oftast fast i den typ som bilden redan har. Att konvertera från ett bildformat till ett annat är sällan bra då du tappar kvalitet i konverteringen. Mer intressant är det om du skapar egna bilder i tex Photoshop och kan välja vilket format och kvalitet som bilden skall visas i. Läs mer om de vanligaste bildformaten.

Det som däremot är intressant att göra med redan skapade bilder är att optimera dem och se till att bilden får en mindre filstorlek. Denna funktionen finns i de flesta bildredigeringsprogram men det finns också tjänster på nätet för detta. Här brukar jag använda tinypng som komprimerar både jpeg och png på ett bra sätt.

5.3.4.3 Nya bildformat

Som du säkert märkt i dina egna prestandatester så påverkas en webbsidas pretstande ganska mycket av bilderna som finns på sidan. Även om vi minskar den faktiska storleken på våra bilder och 9komprimerar dem så mycket det bara går så kan vi bara göra detta till en viss gräns innan vi påverkar bildens kvalitet. Det finns några nya bildformat och av dessa har WebP blivit mest populärt. WebP skapades redan 2010 men det är först de senaste åren som användningen har ökat och mycket beror på att så länge inte alla webbläsare stödjer en teknik så har den svårt att slå igenom. Kika på caniuse.com för att se vilka bildformat som stödjs av respektive webbläsare.

5.3.4.4 Bildredigeringsprogram

Denna kursen kräver inte att du skall kunna skapa egna bilder i ett bildredigeringsprogram men om du är van vid att använda tex PhotoShop så har du ju där ett verktyg som hjälper dig att skapa content till dina webbsidor. Det finns användbara program såsom Gimp att ladda ner från nätet och det finns också flera kraftfulla photoshopliknande onlineapplikationer.

5.4 Tillgänglighet

Tillgänglighet på webben innebär att vi hela tiden måste tänka på att skapa webbsidor som är anpassade för alla, eller i varje fall för så många som möjligt. Ungefär var femte person har behov av någon form av tillgänglighetsanpassning, här hittar du exempel på användare med olika behov.

W3.org tar fram Web Content Accessibility Guidelines (WCAG) 2.0 som är guidelines för hur webbplatser med god tillgänglighet skall skapas. Det finns flera checklistor på nätet att följa och många av dem är inriktade på att myndigheter och organisationer skall vara förutseende att skapa god tillgänglighet för sina webbplatser. Om vi kikar på WCAG 2.0 Riktlinje så finns det fyra stycken principer som den som utvecklar eller publicerar information på webben bör ta hänsyn till.

Princip 1: Möjlig att uppfatta – Information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#perceivable, avläst 2020-09-28.

Princip 2: Hanterbar - Komponenter i ett användargränssnitt och navigering måste vara hanterbara.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#operable, avläst 2020-09-28.

Princip 3: Begriplig - Information och hantering av användargränssnitt måste vara begriplig.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#understandable, avläst 2020-09-28.

Princip 4: Robust - Innehåll måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av olika användarprogram, inklusive hjälpmedel.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#robust, avläst 2020-09-28.

Innan vi kikar vidare lite mer detaljerat så behöver vi få koll på vissa saker. DOS-lagen är det första och det står för Lag om tillgänglighet till digital offentlig service och är en lag som tagits fram för att statliga organisationer skall tvingas hålla en viss kvalitet i sin tillgänglighet. WCAG har tre nivåer som man behöver förhålla sig till, A (lägsta nivån), AA och AAA (högsta nivån) där lägsta nivån är relevant även för våra applikationer. Under 2025 så införs också Tillgänglighetsdirektivet 2025 som är ett krav från EU och som kompletterar DOS-lagen så att det även ställs krav att även företagens digitala tjänster har god tillgänglighet.

5.4.1 Webbriktlinjer.se

DIGG (Myndigheten för digital förvaltning) har en hemsida,Webbriktlinjer, där de listar alla riktlinjer för tillgänglighet på webben. Här går det att visa alla riktlinjer men också söka efter alla WCAG-krav på nivå A, vilket är den lägsta nivån och de kraven som är mest aktuella för oss. För oss är det naturligtvis intressant att kika på alla krav som gäller koden också.

Det finns andra tjänster som är intressanta att kika på när det gäller tillgänglighet. Webaim har relativt tydliga instruktioner vad varje krav innehåller på ett lättöverskådligt sätt och weboverhauls har en smidig checklista som kan användas när du testar av en webbsida.

5.4.2 Tjänster för att testa tillgänglighet

Nu är det ju massor av principer, riktlinjer och tillgänglighetsaspekter att ta hänsyn till. Som tur är så finns det flera verktyg för att få hjälp att bygga tillgängliga webbplatser. Vi skall kika på några av dessa.

• wave.webaim.org är en enkel webbtjänst för att mäta tillgängligheten. WAVE finns som tillägg till flera webbläsare. Fördelen med denna plugin är att du kan testa sidan utan att behöva ladda upp den på din domän.
• Eiii Page Checker testar din kod mot WCAG 20 regelverk. Här får du också tips på hur du kan rätta koden för att följa reglerna.
• En sida, PageSpeed Insights, som vi använde tidigare när vi kollade på prestanda ger också tips på tillgänglighet och även lite annat smått och gott som kollas. Vill man gå på djupet av en av testerna kanske det inte är den bästa sidan, men som en generell översikt över vad som bäst behöver förbättras så borde den fungera bra.

5.5 Redovisning

5.5.1 Frivilliga uppgifter

Ett ganska teoritungt moment där du förhoppningsvis har lärt dig en hel del saker som givit dig inspiration till att förändra webbsidor du har byggt tidigare, söka mer information om något område vi har tagit upp under momentet eller skapat sug att bygga någon ny webbsida.

Har du tid över så använd denna på något bra sätt inom webbutveckling. Har du planer på att göra ditt gymnasiearbete inom webbutveckling så kanske delar av detta momentet kommer vara en del av det arbetet.