HEJO MAIL - HTML och CSS för

Examensarbete HEJO MAIL - HTML och CSS för email Karolina Samuelsson 1986-07-17 Ämne: Datavetenskap Nivå: B Kurskod: 1DV40E

Abstrakt HEJO MAIL HTML och CSS för email handlar precis som titeln antyder om användandet av HTML och CSS för att utforma e-postmeddelanden och är en undersökning över vilka standarder som finns eller åtminstone borde finnas. Viktiga fraser vid informationssökningen har varit Html Email, Email Standards och Email Programming. Resultatet är tänkt att appliceras på HEJO MAIL, som är en applikation för utskick av nyhets- och informationsbrev som idag inte fungerar fullt ut. Resultatet är något förvånande då standarder specifikt för email saknas och har ersatts med rekommendationer, resultatet innefattar en sammanställning av rekommendationer från tre olika källor som valts ut. Dessa rekommendationer har även testats för att verifiera att det faktiskt fungerar med hjälp av 11 stycken testmail. Diskussionen innehåller ett förslag på en praktisk lösning med modultänk för HEJO MAIL samt ett försök att sammanfatta arbetet och återknyta till frågeställningarna. Abstract "HEJO MAIL - HTML and CSS for email" is like the title suggests a thesis about the use of HTML and CSS to design electronic mail and what standards there are to be applied, or at least should be. Key phrases in the search for information have been "HTML Email", "Email Standards" and "Email Programming". The results are intended to be applied on HEJO MAIL, which is an application for sending news and information letters via email that is not working properly. The result is somewhat surprising since standards specific for email do not exist and have been replaced with general recommendations, the result consists of a compilation of recommendations from three different sources that have been selected. These recommendations have also been tested to verify that they are actually functioning by the creation of 11 emails for testing. The discussion part of the thesis includes a suggestion of a practical solution with modular structure for HEJO MAIL and an attempt to summarize the work and the questions of issue. Karolina Samuelsson - II-

Förord Arbetet har utförts som ett avslutande examensarbete, den sista pusselbiten, för högskoleprogrammet Webbprogrammering vid nuvarande Linnéuniversitetet (tidigare Högskolan i Kalmar). Idén till det här arbetet kommer ifrån företaget HEJO Interactive som har en tjänst, HEJO MAIL, för utskick av nyhets- och informationsbrev som idag inte fungerar helt tillfredställande. När arbetet påbörjades fanns någon slags föreställning om att jag snabbt och lätt skulle leta upp standarder för email i en välskriven bok, sammanställa detta och sedan snabbt hoppa på implementering av tjänsten det är ju så det brukar gå till! Man är ovan vid att den research man gör faktiskt får ta tid och räknas, oftast brukar det vara effektiv implementationstid som räknas och syns utåt så det var en viktig lärdom jag fick med mig. Så här efteråt känns ändå resultatet som det bästa av allt - att jag har skapat en rejäl teoretisk grund att stå på, kommit fram till resultat som faktiskt går att bevisa och som är pålitliga, resultat som jag med stolthet kan presentera för min uppdragsgivare. Jag skulle slutligen vilja rikta ett stort tack till Johan Henriksson och Robert Nilsson på HEJO Interactive för att de gett mig den här möjligheten och för att de tagit sig tid och varit ett gott stöd under projekttiden. Jag skulle även vilja tacka Daniel Toll som varit min handledare vid Linnéuniversitetet och som kommit med uppmuntrande och hjälpsamma kommentarer, främst vad gäller utformandet av rapporten. Ett sista tack går till de personer i min omgivning; familj, vänner och kurskamrater som stundtals fått stå ut med mitt inofficiella gnäll. Karolina Samuelsson - III-

Innehållsförteckning 1. Introduktion... 1 2. Bakgrund... 2 2.1 Verksamhetsbeskrivning... 2 2.2 Teoretisk bakgrund... 2 2.2.1 HTML... 2 2.2.2 CSS... 3 2.2.3 Emailklienter... 4 2.3 Avgränsningar... 4 3. Mål... 5 4. Genomförande... 6 4.1 Metod... 6 4.2 Metoddiskussion... 7 5. Resultat... 9 5.1 Rekommendationer... 9 5.1.1 Email Standards Project... 9 5.1.2 Campaign Monitor... 12 5.1.3 Mail Chimp... 13 5.2 Tester... 15 5.2.1 Testmail 1... 18 5.2.2 Testmail 2... 24 5.2.3 Testmail 3... 25 5.2.4 Exempelmail 1... 26 5.2.5 Exempelmail 1.1... 26 5.2.6 Testmail 4... 28 5.2.7 Testmail 4.1... 29 5.2.8 Testmail 5 5.1... 29 5.2.9 Testmail 6... 32 5.2.10 Exempelmail 2... 33 6. Diskussion... 34 6.1.1 Återkoppling till frågeställningar... 34 Karolina Samuelsson - IV-

6.1.2 Framtida utveckling... 37 7. Källförteckning... 38 7.1 Elektroniska källor... 38 Karolina Samuelsson - V-

1. Introduktion Arbetet är till stor del en teoretisk undersökning av hur HTML och CSS bör kombineras och utformas för att ge ett gott resultat vid utformandet av email och tolkning i emailklienterna. I nuläget ser resultatet ut som man tänkt sig i webbläsaren men inte när det senare tolkas av den specifika emailklient som användaren har och dessa problem har alltså sin grund i den HTML- och CSS-kod som är själva kärnan i mailet. Tanken var därför att försöka hitta vilka standarder som gäller för utformandet av email vilket visade sig vara lättare sagt än gjort. Efter att resultaten sammanställts har de även testats genom ett flertal testmail för att försöka göra dem mer pålitliga än andra resultat man kan hitta via internet, till exempel. Detta borde göra resultatet intressant även för andra utvecklare av email. Ett grundläggande syfte med arbetet, från högskolans sida, är att få chans att pröva de kunskaper man tillgodogjort sig under två års utbildning inom webbprogrammering och HTML och CSS för webben är en av grundstenarna i utbildningen. De har varit inblandat i stora delar av densamme, ända sedan starten. En undersökning av andra användningsområden utöver ren webbutveckling kändes därför klart intressant och givande. 1

2. Bakgrund I följande avsnitt beskrivs problemområdet mer ingående. Vad har arbetet för utgångsläge och var kommer fokus att ligga? Avsnittet innehåller även en kortare teoretisk bakgrund med viktiga begrepp inom arbetet. 2.1 Verksamhetsbeskrivning HEJO MAIL är en existerande tjänst som är tänkt att användas för att göra utskick av nyhets- eller informationsbrev. Man riktar sig till medelstora företag och föreningar som har tillräckligt god ekonomi för att engagera sig i marknadsföring men som inte vill anlita en reklambyrå. Målet är en enkel och lättanvänd tjänst som ska underlätta för användaren att göra större utskick till sina kunder. Man använder sig idag av en editor inbyggd i tjänsten där användaren själv kan lägga in den text de vill ha med, ändra färg och skapa rubriker och de kan även lägga till bilder. Det finns en funktion för att förhandsgranska, den här delen stämmer mycket bra överens med de kommandon användaren skrivit in i editorn. Bakom scenen förvandlas dessa kommandon och val till HTML-kod med inline CSS som blir själva kärnan i mailet man vill skicka iväg och det är här man stött på problem, vissa mailklienter tolkar inte den genererade koden på önskvärt sätt. Problemet rör i första hand placeringen av bilder och text som inte följer de direktiv som användaren gett vilket i sin tur innebär en negativ upplevelse. Självklart vill man på HEJO Interactive försöka komma till rätta med det här problemet för att kunna erbjuda tjänsten till sina kunder. 2.2 Teoretisk bakgrund 2.2.1 HTML HTML står för Hyper Text Markup Language och är det dominerande språket för en standardiserad kodning av till exempel webbsidor. Tanken med denna standard är att man ska kunna strukturera upp sina HTML-dokument med hjälp av olika element, såkallade taggar. HTML är alltså inget programmeringsspråk utan snarare ett märkningsspråk (eng. markup language). HTML taggar anger till exempel hur texten 2

man skrivit är indelad i stycken, rubriker, om det finns några länkar eller bilder och så vidare. Det finns även taggar som har med presentation att göra som kan ändra färg på texten eller göra den fetmarkerad men dessa taggar anses föråldrade och man bör undvika att använda dem överhuvudtaget och istället använda sig av CSS. HTML finns i vad som skulle kunna ses som flera olika versioner där olika taggar används och tillåts på olika sätt. I dagsläget är den mest använda versionen HTML 4.0 som i sin tur kan delas in i tre Dokumenttyps Definitioner - DTD (eng. Document Type Definition) - Frameset, Transitional och Strict som används för att validera dina HTML-dokument. I dessa definitioner som man refererar till i HTML-dokumenten finns det specificerat vilka taggar som är okej att använda och hur. (Källa: W3Schools HTML) 2.2.2 CSS CSS står för Cascading Style Sheets. Medan HTML koden har hand om själva strukturen av de dokument man skriver används CSS för att styra presentationen. Man kan med hjälp av CSS bestämma vilken positionering, bredd eller färg ett visst element ska ha. Det finns tre olika sätt för användning av såkallade stilmallar (eng. stylesheets): 1. Man kopplar koden direkt på elementet i stil med <p style= color: red; >, detta kallas att använda sig av inline CSS. Detta sätt anses dock vara på utgående eftersom det är svårt att underhålla och skapar tunga HTML-dokument. 2. Man använder sig av STYLE -taggen som placeras inom HTML-dokumentets HEAD -sektion enligt <style type= text/css >---Stildefinitioner---</style>. Elementen anropas sedan via sin typ, sitt id eller en klass till exempel kommandot p { color:red; } skulle medföra att all text inom P -taggar färgas röd. Detta sätt kallas inbäddad (eng. embedded) CSS. 3. Man länkar till ett externt CSS-dokument genom en LINK -tagg enligt <link href= myexternalstylesheet.css rel= stylesheet type= text/css /> Strukturen på detta dokument liknar till stor grad det som i ovan nämnda punkt placeras inom STYLE -taggen där man alltså kopplar egenskaper till element via typ, id eller klass. Detta sätt brukar anses som det mest optimala eftersom ett och samma dokument går 3

att applicera på flera HTML-dokument samtidigt, det påverkar inte heller laddningen av HTML-strukturen eftersom dessa skiljs åt. (Källa: W3Schools CSS) 2.2.3 Emailklienter En emailklient är ett verktyg för att hantera, läsa och formatera email. Det finns olika typer av klienter och denna rapport kommer fokusera och skilja på två av dessa: Plattforms- och webbaserade. De webbaserade klienterna kan endast nås via en webbläsare och ingen installation av några särskilda program behövs på datorn vilket medför att man kan logga in och nå sina email från i princip vilken dator man vill. Med plattformsbaserade klienter avses å andra sidan de emailklienter som mer liknar ett program som installeras direkt på datorn och går att nå utan att behöva gå vägen via en webbläsare, det som görs är dock oftast att man kopplar en webbaserad klient till den plattformsbaserade klient man installerat. 2.3 Avgränsningar Arbetet kommer i huvudsak inriktas på att undersöka hur den HTML- och CSS-kod som ett email består av bör se ut för att kunna tolkas och presenteras korrekt av de mest använda mailklienterna. En sådan begränsning grundar sig i att kunden vill ha ett utförligt och pålitligt resultat och en stabil lösning samt att arbetet endast sträcker sig över dryga 10 veckor. Arbetet kommer att inriktas på de mest använda emailklienterna efter önskemål från HEJO Interactive. Det vore även önskvärt att hitta förslag på hur detta resultat skulle kunna användas rent praktiskt även om det inte finns tid för en implementation av en sådan lösning. 4

3. Mål Målet med projektarbetet är alltså att hitta en fungerande lösning vad gäller utskick av nyhets- och informationsbrev. De frågeställningar arbetet ämnar besvara är: Finns det någon gemensam standard för HTML och CSS i email? o Vilka rekommendationer finns det? Fungerar dessa standarder eller rekommendationer som förväntat i emailklienterna? Hur skulle detta kunna användas rent praktiskt? 5

4. Genomförande Under denna rubrik beskrivs hur arbetet bedrivits, hur informationssökningarna gått till och kapitlet avslutas med en metoddiskussion gällande för- och nackdelar med de tillvägagångssätt och metoder som tillämpats. 4.1 Metod Stora delar av det tio veckor långa arbetet har varit förlagt på HEJO Interactives kontor i Alingsås på fasta kontorstider. På kontoret har det även funnits tillgång till ständig kundkontakt och feedback samt möjligheter till backup och säkerhetskopior av arbetet via företagets servrar. Som projektmodell har en variant baserad på Unified Process (hädanefter kallad UP) använts. UP är en iterativ utvecklingsmodell som innebär att man arbetar i iterationer, i det här fallet veckovis indelade perioder, som alla innefattar de fem olika delarna; Analys/Design, Krav, Implementation, Test, Leverans. Man arbetar alltså kontinuerligt med att t.ex. uppdatera vilka krav som finns på projektet, ingenting är ristat i sten. UP är även indelat i fyra större faser; Inception, Elaboration, Construction och Transition med olika fokus på olika delmoment, Inception innehåller t.ex. större andel Krav eller Analys än vad Construction gör som har större fokus på implementation. En av de mest krävande delarna i arbetet har varit rapporten. Den har tillägnats mycket tid och har uppdaterats kontinuerligt under arbetet. Till en början skedde uppdateringarna mer sällan i och med att mycket material inte var klart. Ett stort steg framåt kom i och med att resultatdelen utvecklades. Stora delar av arbetet har varit teoretiskt och inriktat på att hitta information för att kunna försöka besvara de frågeställningar som arbetet varit inriktat på. Sökningen har varit indelad i två delar: Del ett inriktades på att försöka hitta vetenskapliga artiklar och litteratur inom området. Sökningar efter artiklar gjordes främst genom sökningar i databasen DiVA som finns tillgänglig genom Linneuniversitetet. Litteratursökningar gjordes genom den svenska bibliotekstjänsten Libris samt via den onlinebaserade boktjänsten Ebrary. Då detta resultat inte gav önskat utfall inleddes del två av sökningarna som var något mer informell och skedde via internet och sökmotorer. Sökfraser som använts flitigt har varit Html Email, Email Standards och Email Programming. Här fanns resultat i form av artiklar, bloggposter och guider. 6

För att öka pålitligheten i resultatet bestämdes att informationen som hittades inte enbart skulle sammanställas utan även objektivt testas genom 11 stycken test- och exempelmail. De svarar på frågan Fungerar rekommendationerna? och visar att Så här skulle ett email kunna se ut. De har testats i nio olika emailklienter, fem plattformsbaserade och fyra webbaserade klienter. De plattformsbaserade klienterna som använts är Apple Mail 3.6, Mozillas Thunderbird 5.0, Microsoft Outlook 2007 och Express samt Windows Live Mail 2009. Webbklienterna var Googles Gmail, Windows Live Hotmail, Outlook Web Access och Yahoo. Eftersom de webbaserade klienterna till viss del påverkas av vilken webbläsare som använts har resultatet för dessa även testats i fem olika browsers; Firefox 3.6.3, Google Chrome 4.1, Internet Explorer 8, Opera 10.53 och Safari 3.1.2. Samtliga mail utformades efter HTML Transitional 4.0. Mailens utseende kontrollerades i webbläsaren Firefox med godkänt resultat innan de skickades vidare ut till emailklienterna. 4.2 Metoddiskussion Att arbetet utförs under en pressad tid på endast dryga tio veckor är en klar nackdel som påverkar resultatet, man önskar att det funnits mer tid för att kunna komma fram till ett mer komplett resultat. Samtidigt är det även viktigt att begränsa arbetet och hitta fokus och tydliga avgränsningar för arbetet och specificera vilka resultat man vill uppnå så att det inte svävar iväg vilket tidsbegränsningen krävde per automatik. Som distansstudent är det svårt med fasta rutiner och arbetet blir gärna ostrukturerat och hattigt. Det innebär att man aldrig riktigt kan känna sig ledig eller mäta de resultat man uppnår i förhållande till tiden man spenderat eftersom allt blir väldigt flytande över tid och rum. Att med denna utgångspunkt flytta sitt arbete hemifrån till ett kontor med fasta arbetstider kändes som en befrielse och en fantastisk fördel! Det har varit lätt att skilja på när man varit student och när man varit privatperson och man har med gott samvete kunnat ha ledigt röda dagar, till exempel. Att tillämpa Unified Process (UP) under arbetet kändes naturligt eftersom detta är den metod vi kommit i kontakt med under tidigare kurser och arbeten. Det kändes inte befogat eller nödvändigt att börja leta efter alternativa projektmodeller i detta skede utan snarare att anpassa UP efter de egna behoven. 7

En oväntad vändning i arbetet var när utbudet av vetenskapliga artiklar och relevant litteratur inom området visade sig vara såpass tunt, för att inte säga obefintligt. Det kändes svårt att navigera bland resultat från sökmotorer och att få en känsla av vilka artiklar och guider som är pålitliga och vilka som författas på mindre seriösa grunder. Det var därför viktigt att dra alla resultat över en kam och först läsa igenom dem och sedan testa dem istället för att blåögt bestämma sig för att ett resultat verkade mer pålitligt och påkostat än något annat, det var en viktig lärdom att vara kritisk i sitt arbete. Det kändes även viktigt att inte förkasta några sökresultat på grund av textens formatering eller webbsidans utseende och tillämpa ordspråket Det är insidan som räknas, i det här fallet innehållet. 8

5. Resultat I detta kapitel presenteras resultaten av informationssökningen och vad testningen har gett för utslag samt en sammanställning av hur email bör formateras för att få ett så gott och jämlikt resultat som möjligt i de olika emailklienterna. 5.1 Rekommendationer Det resultat som informationssökningen gett är att det finns inga direkta standarder som är inriktade på just användandet av HTML och CSS i email. De standarder som finns är för webben och rent teoretiskt är det dessa man skall utgå ifrån. I praktiken fungerar det dock inte fullt ut. Även om standarder saknas finns det gott om rekommendationer för hur email bör utformas. Dessa rekommendationer kommer dock från webbsidor och artiklar som inte är vetenskapliga, artiklar som alltså saknar till exempel granskningsreferenser, samtidigt som många av dem är färgade av skribentens åsikter eller eventuella företagstillhörigheter. Här nedan presenteras och sammanställs dessa rekommendationer för att sedan kopplas till testmailen i den mån de anses användbara för HEJO MAIL. 5.1.1 Email Standards Project Efter Email Standards Projects (hädanefter ESP) undersökningar 2007 delade de in emailklienterna i två kategorier: De som har gediget stöd och de som rekommenderas förbättringar. Indelningen såg ut som följer: Gediget stöd Apple Mail Mozilla Thunderbird Windows Live Mail Yahoo! Mail Förbättringar rekommenderas Google Gmail Microsoft Outlook 2007 9

Windows Live Hotmail I tabell 5.1.1.1-5.1.1.4 ges en överblick över vilka egenskaper som testades och hur stödet för dessa var fördelat i emailklienterna. Tabell 5.1.1.1 och 5.1.1.2 visar egenskaper som satts till hög prioritet, essentiella egenskaper som det är viktigt att det finns stöd för enligt ESP. Dessa egenskaper hanterar positionering och färgsättning av både element och text. Tabell 5.1.1.1 De högt prioriterade egenskapernas stöd i de plattformsbaserade emailklienterna Tabell 5.1.1.2 De högt prioriterade egenskapernas stöd i de webbaserade emailklienterna 10

Tabell 5.1.1.3 och 5.1.1.4 som följer visar egenskaper som är mer åt det förskönande hållet, egenskaper som hanterar till exempel textens utseende utöver färg eller kantlinjer. Dessa är inte lika högt prioriterade. Tabell 5.1.1.3 De lägre prioriterade egenskapernas stöd i de plattformsbaserade emailklienterna Tabell 5.1.1.4 De lägre prioriterade egenskapernas stöd i de webbaserade emailklienterna ESP rekommenderar att bilder som enbart rör utseende och egentligen inte har någon inverkan på innehållet placeras i mailet med hjälp av egenskapen background-image eftersom separation mellan innehåll och presentation alltid är att föredra samt för att det underlättar för de enheter som inte stödjer CSS, till exempel mobiltelefoner. De önskar även att all CSS placeras inbäddad för att öka tillgängligheten och för att få ner dokumentets storlek i och med att mycket av koden är möjligt att återanvända. 11

5.1.2 Campaign Monitor I artikeln Email design guidelines från Campaign Monitor (hädanefter CM) börjar man med att påpeka att webben är i ständig framfart och att standarderna där utvecklas kontinuerligt i en rasande fart men att för emailklienter är det helt tvärtom antingen står utvecklingen stilla eller så går utvecklingen bakåt, det man syftar på då är releasen av Outlook 2007 som istället för utökat stöd tog ett enormt steg tillbaka genom att byta renderingsmotor från Internet Explorer till ordhanteraren Microsoft Word. Man rekommenderar till en början fokus på tre saker: 1. Håll det enkelt. Ju mer avancerat och komplext mailet är utvecklat desto större risk är det att någon del av det inte tolkas korrekt av emailklienterna. 2. Ta kodandet ett drygt årtionde tillbaka i tiden, tillbaka till nästlade tabeller och inline CSS. 3. Testkör dina mail kontinuerligt. Bara för att det ser klockrent ut en dag kan det släppas en uppdatering och se helt förkastligt ut redan nästa vecka. 5.1.2.1 Layoutrekommendationer När det gäller den praktiska utformningen av email rekommenderar CM användandet av tabeller för planering av layouten och positionering. De anser vidare att den mest pålitliga aspekten vad gäller width är att ange önskad bredd i pixlar på varenda cell i tabellen jämfört med att sätta bredden direkt på tabellen eller via CSS, att använda pixlar är viktigt eftersom användandet av procent lämnar allt för mycket utrymme för egen tolkning. Ingen breddsättning bör heller lämnas upp till emailklienten, det kan sluta precis hursomhelst. Vidare skriver CM att en del klienter inte tolkar bakgrundsfärg som är satt via CSS eller på BODY -taggen och rekommenderar en yttre tabell som täcker hela den önskade ytan, man går här emot lite av det man tidigare sagt och rekommenderar att bredden sätts till 100 %. Enligt artikeln kan det även vara svårt med utrymme omkring paragrafer, P -taggar, främst i Yahoos mailklient. Har man ett mail som är oerhört känsligt vad gäller avstånd och att varje liten pixel räknas bör man sätta en såkallad padding direkt på varje element det berör. 5.1.2.2 CSS rekommendationer När det kommer till rekommendationer gällande CSS skriver CM att all CSS bör flyttas inline, detta på grund av att vissa av de webbaserade klienterna skalar bort dokumentets HEAD -tagg och i vissa fall även BODY -taggen där inbäddad CSS i normala fall brukar placeras. Man bör enligt rekommendationerna inte heller använda 12

sig av CSS-förkortningar såsom att deklarera alla egenskaper för texten efter en fontdeklaration (font: 17px, Tahoma;) utan att man delar upp det i textstorlek (font-size) och teckensnitt (font-family). Detta gäller även användandet av förkortade koder för hexadecimal färgsättning, för webben fungerar det alldeles utmärkt att förkorta den svarta koden #000000 till #000 medan detta bör undvikas vid utformandet av email eftersom detta kan ställa till problem. Slutligen vad gäller CSS höjs en varningens flagga när det gäller egenskapen float, den saknar stöd i till exempel Outlook 2007 och man rekommenderar ett något föråldrat attribut som placeras direkt på elementet det gäller som kallas align. 5.1.2.3 Bildrekommendationer Sista avsnittet i artikeln som gäller rekommendation för klient- och webbaserade handlar om hantering av bilder. Den första punkten som CM rekommenderar att man tänker på är att många bilder blockeras automatiskt av emailklienterna. Det kan därför vara riskabelt att förlita allt för stor del av sitt mail på bilder vad gäller layouten. Nästa punkt gäller att man ska ange vilken storlek man önskar på bilderna, annars har de flesta klienterna fördefinierade storlekar som de tillämpar om ingen storlek angetts vilket kan ge ett oväntat resultat. Vad gäller filtypen för bilder är det GIF eller JPG som rekommenderas, det betyder en något högre filstorlek men ger bättre stöd framförallt i klienten Lotus. Vid användande av bilder som bakgrund bör man alltid ha en bakgrundsfärg tillgänglig som alternativ för de emailklienter som inte stödjer CSSegenskapen background-image. En annan viktig aspekt är att alla bilder bör förses med alt -attributet. Detta är ett attribut som IMG -taggen kräver och som är tänkt att visas om en bild har blockerats eller inte kan visas av annan anledning. Man kan dock inte räkna med att alt -attributet visas i alla lägen eftersom det även är vanligt att det skalas bort av bland annat Outlook 2007, Hotmail och Apple Mail. 5.1.3 Mail Chimp Free guide från Mail Chimp skiljer sig något från de andra källorna, den är mer omfattande och innehåller även information om email i allmänhet, om hur de fungerar rent tekniskt och så vidare, men det finns även en del rekommendationer gällande HTML och CSS och det är dessa som kommer att sammanfattas nedan. 13

5.1.3.1 Layoutrekommendationer Man bör ha en bredd på mailet som ligger på 500-600 pixlar, det är alltså andra riktlinjer än vad som gäller för webben på grund av att utrymmet är mycket mer begränsat och många användare läser mailen direkt i den förhandsvyn som finns främst i de plattformsbaserade klienterna. Layouter bör vara enkla och inte vara nästlade allt för djupt även om tabeller är vad som rekommenderas för positionering och skapandet av kolumner. Även om användandet av DIV -taggar och CSS är det enda vettiga alternativet för utveckling på webben fungerar det enligt guiden inte i email. Man bör se upp så att det inte blir alltför många rader och kolumner i tabellerna dock. Vad man bör tänka på när det gäller tabeller är attributet colspan som tillåter celler att löpa över en eller flera tabeller, risken finns att detta ignoreras i klienten. Så istället för att nästla tabeller och överanvända colspan kan det vara läge att använda fler tabeller istället. Man kan som exempel använda separata tabeller för headern, huvudinnehållet och footern. Nästa del med rekommendationer gäller de klienter som är webbaserade, alltså Gmail, Hotmail och Yahoo. Först och främst lyfter man fram det faktum att HTML, HEAD och BODY -taggarna kommer att skalas bort från dina email för att förhindra att det du angett kommer i konflikt med de deklarationer som finns för webbläsaren och klienten. Det betyder, precis som fanns att läsa i CMs artikel, att ingen bakgrundsfärg som är deklarerad i BODY -taggen kommer att synas. Lösningen är en tabell som täcker hela dokumentet och att man sedan sätter en bakgrundsfärg på detta element. 5.1.3.2 CSS rekommendationer Att HTML, HEAD och BODY -taggarna skalas bort betyder även att om man vill länka in CSS eller ha den inbäddad kommer detta skalas bort om det ligger i HEAD -taggen och bör därför placeras precis nedanför BODY -deklarationen, strax ovanför den ordinarie HTML-koden. Man nämner även i det här avsnittet att i vissa klienter skalas den inbäddade CSS:en bort, troligen av samma orsak som ovanstående taggar; för att det inte ska komma i konflikt med CSS:en för klienten. Även om inbäddad CSS skalas bort och det inte finns stöd för positionering med CSS rekommenderas användandet för formateringen av exempelvis text och färger. Dokumentet bör rent strukturmässigt byggas så att det misslyckas med stil, skulle CSS:en av någon anledning inte nå fram ska mailet gå att läsa och se acceptabelt ut. Detta kan endast försäkras genom att man faktiskt testar. 14

5.1.3.3 Bild- och övriga grafiska rekommendationer Rekommendationer gällande bilder är att dessa bör förvaras på en server och länkas in via den absoluta sökvägen jämfört med att bifoga bildfiler i mailet. Att bifoga dem skulle dels öka storleken radikalt samtidigt som det skulle kunna bli svårigheter med placering och formatering av dessa filer. Även om det är lockande avråder Mail Chimp slutligen från att använda tekniker som Flash, Javascript och ActiveX eftersom det finns ytterst lite stöd för dessa i mailklienterna vilket gör användandet meningslöst. 5.2 Tester De 11 test- och exempelmailen är i mångt och mycket väldigt lika i sin utformning, de innehåller samma typ av element och egenskaper för att testa de mest grundläggande funktionerna med inspiration från den existerande tjänsten. De testar även olika tekniker och kombinationer av HTML och CSS för layout och positionering. Den HTML som testats är: DIV H1-H6 IMG OL/LI P SPAN TABLE UL/LI Den CSS som testats är: Background-color Color Float Font-family Font-size Margin Padding Text-align 15

Del ett av testmailet som illustreras i bild 5.2.1 innehåller och testar de olika typerna av rubriker som finns, rubrikerna har ändrad färg (lila eller orange) och är placerade antingen oförändrat till vänster eller till höger i mailet. Därefter testas paragrafer och stycken. Första stycket är en SPAN -tagg som är turkos och i teckensnittet Arial. Nästa stycke är en P -tagg som är centrerad, brun och i teckensnittet Courier. Det sista stycket är en DIV -tagg som är placerad till höger, är röd och i Tahoma. Bild 5.2.1 Önskat resultat, del ett. Del två som illustreras i och med bild 5.2.2 testar positionering av bilder. Tanken är att en bild ska placeras flytande vid sidan om ett textstycke. I det här fallet testas två olika varianter, det övre stycket är placerat i en P -tagg och det nedre i en SPAN - tagg. Teckensnittet är satt till Verdana för båda dessa block. Nedanför dessa bildblock finns en tabell. Tanken med denna tabell är att testa huruvida detta alternativ fungerar för att skapa till exempel kolumner. Tabellen har 16

även placerats centrerat för att testa positionering. Tecktensnittet i tabellen är Times New Roman. Bild 5.2.2 Önskat resultat, del två. Del tre, även bild 5.2.3, innehåller sex olika block med listelement. Placering av dessa element har testats genom att placera dem till vänster (standard), i mitten och till höger. Längst ner finns en paragraf som talar om vem som utformat mailet samt en länk med ändrad färg för att testa stödet för detta. 17

Bild 5.2.3 Önskat resultat, del tre. Innan genomgången av testmailen påbörjas finns det ytterligare en sak att nämna angående den webbaserade emailklienten Outlook Web Access. Den finns i två utföranden: Den ser ut och fungerar på ett sätt i Internet Explorer och vitt skilt från detta i de flesta andra webbläsarna. Resultaten grupperas därför efter dessa två kategorier. Nedan följer således en presentation av testmailen var för sig, presentationen innehåller en sammanfattning av vad de ämnade testa samt vad de gav för utslag och resultat. 5.2.1 Testmail 1 Testmail 1 är utformat med hjälp av en standard DIV -layout som vanligtvis används vid utveckling för webben, detta i kombination med CSS som flyttats inline och alltså ligger direkt på elementen efter rekommendationerna från både Campaign Monitor och Mail Chimp. För centrering av den yttre DIV -taggen används CSS-egenskapen margin som är satt till auto. 18

Ett första gemensamt problem som dyker upp är att de P - och SPAN -taggar som innehåller bilder i kombination med text verkar endast vara anpassade efter textens omfattning. Detta skapar problem eftersom bilderna då inkräktar på elementen som ligger nedanför. Problemet illustreras med bild 5.2.1.1. Bild 5.2.1.1 P - och SPAN -taggarna i Gmail, Firefox Ett annat generellt problem rör webbläsarna Chrome, Safari och Apples mailklient Mail som inte tolkar positioneringen av listelement riktigt som förväntat. Texten blir centrerad men den (i de här fallen) punkt eller siffra som definierar listan följer inte med som visas i bild 5.2.1.2. Bild 5.2.1.2 Positionering av listelement i Gmail, Google Chrome 19

5.2.1.1 Resultat testmail 1 Nedan följer en presentation av resultatet i de olika emailklienterna och webbläsarna. Om inget annat anges såg resultatet ut som förväntat med undantag för bildblocken och listelementen. Det som kommenteras är i första hand hur klienten hanterar margin och andra CSS-egenskaper. Apple Mail Margin för positionering fungerar utmärkt. Teckensnitt och färger på textelement okej, Verdana något bold. I och med att den nedre bilden flyter över gränsen för SPAN -taggen påverkar detta tabellen och den flyter upp och lägger sig ovanför bilden. Bild 5.2.1.3 Apple Mail, testmail 1 Outlook 2007 Kan inte hantera margin -, padding - width - eller float -egenskaperna, vilket stämmer överens med Email Standards Projects slutsatser. Mailet täcker därmed hela ytan vilket i det här fallet inte ställer till några visuella problem annat än att den grå bakgrunden faller bort. I och med att float saknas är båda bilderna placerade till vänster och texten börjar i dess nedre kanter, elementen är anpassade efter dess totala storlek. Formateringar vad gäller texter och länkar ser mycket bra ut. 20

Bild 5.2.1.4 Outlook 2007, testmail 1 Outlook Express Mycket bra resultat. Texten fyller i det närmsta upp samma område som bilden i bägge bildblocken och ger därmed ett mycket bra resultat. Utöver detta tolkas även anvisningar för postionering och dessutom ser alla textangivelser ut som förväntat, både vad gäller form och färg. Thunderbird Godkänt på samtliga punkter. Även tolkningen av bildblocken är väldigt nära förväntat resultat. All positionering och text-/länkformatering ser ut som förväntat. Windows Live Mail Även här mycket bra resultat. Endast de HR -taggar som skiljer elementen åt drabbas och suddas ut på grund av bilderna men ingen del flyter över och skapar ett alltigenom negativt resultat. All positionering och text-/länkformatering ser även ut som förväntat. Gmail samtliga browsers Okej med margin för positionering. Saknar Times New Roman på tabellen, övriga teckensnitt helt okej. All positionering av text med hjälp av text-align är okej. Bra padding på styckeselementen. 21

Bild 5.2.1.5 Gmail/Firefox, testmail 1 Hotmail samtliga browsers Kan inte hantera margin för positionering. Tabellen har om inte Times New Roman åtminstone serif-teckensnitt, övriga teckensnitt är också okej. Bra padding på styckeselementen och länken längst ner har önskad färg. Att bilden flyter över i bildblocken påverkar dessvärre även nedan liggande tabell i Hotmail. Att den inte är centrerad beror på att det beordras med hjälp av margin men texten i tabellen får konstig padding i överkant. Outlook Webaccess - Internet Explorer Bild 5.2.1.6 Hotmail/Firefox, testmail 1 22

Kan inte hantera margin för positionering. I övrigt är tolkning av positioneringar och teckenformateringar mycket bra, så även färgsättningar. Det översta bildstycket ser helt okej ut och flyter inte över alls medan den nedre bilden endast flyter över ett par pixlar. - Övriga browsers I övriga webbläsare fungerar det med margin för positionering. Något som däremot ställer till det utöver vad som nämnts tidigare och som ger en mycket negativ upplevelse är den minimala teckenstorleken som ger ett helt oväntat resultat. Teckensnitten och färgsättningar är däremot korrekt tolkade. H1-taggar kan däremot inte heller hanteras och tolkas. Bild 5.2.1.7 Outlook Web Access/Firefox, testmail 1 Yahoo samtliga browsers Margin - positionering okej. Teckensnittet i tabellen är inte Times New Roman, övriga teckensnitt är godkända och så även färgsättning. All positionering av text med hjälp av text-align är okej. Tunt med padding på styckeselementen, enligt artiklarna från Campaign Monitor och Mail Chimp. I webbläsaren Safari när den nedre bilden flyter över lägger sig tabellen ovanför denna. 23

Bild 5.2.1.8 Yahoo/Firefox, testmail 1 Bild 5.2.1.9 Yahoo/Safari, testmail 1 Email Standards Projects resultat stämmer med andra ord ganska bra överens med de resultat som framkommit genom testerna med undantag för Gmail som faktiskt stödjer, åtminstone, de egenskaper som testats här. 5.2.2 Testmail 2 Testmail 2 är utformat i stort sett likadant som testmail 1. Basen är fortfarande en DIV -baserad layout, margin: auto; används för centrering av element och textalign för positionering av text. Eftersom problemet med P - och SPAN -taggarna för bilder verkar vara beroende av textens storlek och omfattning har standardstorleken för text satts till 17px. En annan viktig skillnad från testmail 1 är att all CSS har flyttats från elementen och anropas istället inbäddat i en STYLE -tagg strax under BODY -taggen med hjälp av klasser, id och elementnamn enligt rekommendationer från Email Standards Project. Själva testmomentet består alltså främst i hur emailklienterna hanterar inbäddad CSS. 5.2.2.1 Resultat testmail 2 Resultatet av detta test är mycket gott och det finns endast två undantag; Gmail skalar bort all inbäddad CSS: 24

Bild 5.2.2.1 Gmail/Firefox, testmail 2 Detta är även svaret på varför Gmail fått genomgående nedslag i Email Standard Projects tester som alltså bygger på inbäddad CSS. Outlook Web Access (ej Internet Explorer) tolkar inte önskad generell textstorlek (17px) som angetts på BODY -elementet. All övrig CSS fungerar dock som tänkt vilket skulle kunna betyda att just BODY -taggen skalas bort för att undvika konflikter med webbläsarens direktiv enligt artiklarna från både Campaign Monitor och Mail Chimp. I Internet Explorer finns inte detta problem. Bild 5.2.2.2 Firefox Bild 5.2.2.3 Internet Explorer 5.2.3 Testmail 3 Testmail 3 är utformat för att testa huruvida emailklienterna kan hantera inlänkad CSS. Strukturen är alltså densamme som för testmail 2 men all CSS har lyfts ut och placerats i ett separat dokument som sedan länkats in i HTML-dokumentet via en absolut sökväg. 25

5.2.3.1 Resultat testmail 3 Resultaten kan delas in i två grupper: De med stöd för inlänkad CSS och de som saknar stöd. Stöd för inlänkad CSS: Apple Mail Outlook Express Thunderbird Windows Live Mail Saknat stöd för inlänkad CSS: Gmail Hotmail Outlook 2007 Outlook Web Access Yahoo 5.2.4 Exempelmail 1 Efter dessa tre testmail kändes det som att en relativt klar bild över koden började växa fram och ett exempelmail utformades. Ett försök att komma till rätta med de felformaterade taggarna för bilder sattes en fast storlek på texten inbäddat på BODY -taggen, bilderna sattes även till fasta storlekar med hjälp av HTMLattributen width och height. Margin har helt och hållet bytts ut mot HTMLattributet align för att tillgodo se de klienter som inte stödjer detta. Vad som föll i glömska var dock att varken Gmail eller Outlook Web Access tolkar inbäddad CSS och resultatet blev återigen misslyckat. Placeras önskad textstorlek däremot även på textelementen direkt försvinner detta problem och mailet ger önskat resultat vad gäller dessa bildblock. 5.2.5 Exempelmail 1.1 Även om konstruktionen för bildblocken fungerar och i fallet med exempelmail 1, efter en del justeringar, ger önskat resultat känns metoden ostadig och opålitlig. Det känns inte hållbart att låta bilden och texten vara beroende av varandra storleksmässigt 26

och det går inte heller att lita på att användaren förstår problematiken och anpassar texter efter bilden, eller tvärtom. En ny strategi arbetades därför fram bilder av denna typ, som flyter bredvid en text, placeras inom en tabell med två celler. Texten placeras i en cell och bilden i en egen. Denna lösning fungerar som tänkt i samtliga emailklienter. Bild 5.2.5.1 Gmail, Outlook Web Access och Yahoo 5.2.5.1 Problem exempelmail 1.1 Något som framgår tydligt i och med detta testmail är att då CSS-egenskapen margin bytts ut mot HTML-attributet align misslyckas det i Yahoo vad gäller tabeller. Allra tydligast blir det på tabellen med textinnehåll som inte tar upp hela ytan. 27

Bild 5.2.5.2 Yahoo/Firefox, exempelmail 1.1 Outlook 2007 ställer däremot till med andra problem. Området bakom tabell- och listelement saknar den vita bakgrundsfärgen och den grå bakgrunden lyser igenom. Detta har förmodligen att göra med att en extra DIV -tagg har tillkommit, det finns nu alltså två DIV -taggar, en för att sätta den yttre bakgrundsfärgen till grå och en som fungerar som behållare till mailet och någonstans tolkar Outlook 2007 detta på felaktigt sätt. Bild 5.2.5.3 Outlook 2007, exempelmail 1.1 5.2.6 Testmail 4 Efter flertalet försök att hitta lösningar för de problem som framkom i och med exempelmail 1.1 genom att ändra små detaljer fick återigen en ny strategi arbetas fram 28

för att täcka de luckor som uppkommit. För att kunna särskilja problemen åt inriktas testmail 4 på att hitta en lösning som fungerar som tänkt även i Outlook 2007. Eftersom både Campaign Monitor och Mail Chimp rekommenderar att man använder tabeller för att bygga sina layouter blir detta nästa teststeg. En yttre DIV -tagg ligger kvar även i detta mail för att sköta bakgrundsfärgen då BODY skalas bort men behållaren för själva mailet har bytts ut mot en tabell som har en rad och en cell där all övrig kod placeras. Denna ändring löser det aktuella problemet och samtliga emailklienter visar upp önskat resultat. 5.2.7 Testmail 4.1 Detta testmail är således mer inriktat på att hitta en lösning för problemet i Yahoo och det faktum att align -attributet inte fungerar fullt ut vad gäller tabeller. Idéen till detta testmail kom i samband med att den yttre DIV -taggen i till exempel exempelmail 1 och 1.1 placeras centrerat med hjälp av align vilket fungerar utmärkt, även i Yahoo. Tabellen i fråga kapslas därför in i en DIV -tagg som sätts till align=center, align -attributet tas därmed bort från tabellen helt men ersätts med CSS-egenskapen text-align som talar om att texten i tabellen ska hållas till vänster eftersom den annars hade ärvt den centrerade positionen. Detta löser problemet och mailet ser med andra ord ut helt som man tänkt sig. 5.2.8 Testmail 5 5.1 Syftet med testmail 5 är att arbeta fram en lösning för hur koden skulle kunna se ut senare i själva tjänsten. Tabeller kommer att kapslas in i en DIV -tagg för att positionering ska kunna hanteras på bästa sätt och en tanke är att mailet ska delas in i olika block som alla är inkapslade i en DIV -tagg. 5.2.8.1 Blockindelning enligt testmail 5 29

Bild 5.2.8.1 Block 1 Bild 5.2.8.2 Block 2-3 Bild 5.2.8.3 Block 4 30

Bild 5.2.8.3 Block 5 Bild 5.2.8.4 Block 6-11 Bild 5.2.8.5 Block 12 I testmail 5 är positioneringen delad mellan align -attributet och CSS-egenskapen text-align, i testmail 5.1 däremot är det enhetligt utformat så att de DIV -taggar som fungerar som blockbehållare positioneras med hjälp av align medan texten inuti dessa positioneras med hjälp av text-align. Ett exempel är, som nämnts tidigare, 31

texttabellen i block fem som ligger centrerad i mailet medan texten fortfarande ska hållas i vänsterkanten. 5.2.9 Testmail 6 Det avslutande testmailet är ämnat testa om emailklienterna tolkar bakgrundsfärgen från BODY - eller den heltäckande DIV -taggen. Det är mycket enkelt utformat och innehåller endast den omslutande BODY - taggen, en yttre DIV som dragits in ett par pixlar för att kunna skilja på dem, en tabell som fungerar som behållare som i sin tur innehåller en DIV -tagg som presenterar innehållet i mailet. Bild 5.2.9.1 Återkonstruktion av testmail 6 Dessa resultat kan delas in i tre kategorier: De som kan tolka båda bakgrundsfärgerna, de som endast tolkar bakgrundsfärgen från BODY och de som endast kan tolka bakgrundsfärgen från DIV. BODY: Outlook 2007 BÅDA: Apple Mail Outlook Express Thunderbird Outlook Web Access Windows Live Mail DIV: Gmail Hotmail 32

Outlook Web Access Yahoo 5.2.10 Exempelmail 2 Det sista mailet som utformades var ett exempelmail med anknytning till hur framtida användare kan komma att vilja använda tjänsten. Precis som testmail 5 är det uppbyggt i block; en header som innehåller en topbild, tre block med bilder och flytande text och en footer med en bottenbild som avslutar mailet. Bild 5.2.10.1 Exempelmail 2 Bilderna ligger i varsin tabell och visar även på hur texten kan placeras i förhållande till tabellens övre och nedre kanter samt centrerat. Resultatet ser ut som förväntat i samtliga emailklienter. 33

6. Diskussion Detta kapitel är ett försök att återknyta resultaten till de frågeställningar som finns specificerade under måldelen; tankar om avsaknaden av standarder, hur de rekommendationer som testats bedöms samt ett förslag på en praktisk lösning. 6.1.1 Återkoppling till frågeställningar Finns det någon gemensam standard för HTML och CSS i email? o Vilka rekommendationer finns det? Att det saknas specifika standarder för email känns ganska förvånande då email trots allt är en betydande och stor del av internet i allmänhet. Som nämndes i metoddiskussionen var det en oväntad vändning när mer betrodda resultat saknades, det kändes som en självklarhet att det faktiskt skulle finnas resultat (vetenskapliga artiklar och litteratur) att ta del av! Detta var inget som hade kunnat förutses men absolut en risk som hade behövts räknas in i arbetet. I början av testandet kändes det ganska ljust och faktiskt möjligt att använda sig av webbstandarder då den standardiserade DIV -layouten såg ut som förväntat i 8 av 9 emailklienter, men man ska alltså inte ta ut någonting i förskott! Det hade varit bekvämt att kunna dra slutsatsen att de plattformsbaserade klienterna får så bra resultat eftersom de har andra förutsättningar och har större möjligheter att faktiskt göra som de blir tillsagda medan de webbaserade klienterna jobbar i uppförsbacke och måste tolka resultaten med hänsyn till de specifikationer som finns för vald webbläsare. Så är det säkert också till en viss grad men i och med Email Standards Projects undersökningar bevisar Yahoo att det faktiskt går att utveckla en webbaserad klient med full gott stöd samtidigt som Outlook 2007 visar på någon slags motsats, vilket är oerhört intressant. 2007-2008 kan ses som något av en storhetstid för diskussionen gällande standarder för email, många av de artiklar som jag stött på i arbetet är skrivna under dessa år och även Email Standards Project startades under denna period allt tack vare Outlook 2007. Det är svårt att låta bli att undra varför de ändrade sin renderingsmotor från Internet Explorer, som uppenbarligen fungerade, till Word vilket är detsamma som att ta ett stort steg tillbaka. Det räcker med att jämföra Outlook Express som får goda resultat i testerna jämfört med Outlook 2007 som skapar problem. Express varianten 34

är dessutom en tidigare gratisversion och 2007:an måste köpas i ett större Officepaket. Tack vare eldsjälar och organisationer som främst Email Standards Project och Campaign Monitor förs dialogen dock vidare och rekommendationer för hur man skulle kunna utforma email även idag finns det gott om. Fungerar dessa standarder eller rekommendationer som förväntat i emailklienterna? Jag skulle vilja sammanfatta resultaten av test- och exempelmailen med att de rekommendationer som jag valt att använda mig av absolut går att använda och är pålitliga. Ett undantag som finns är ju dock de resultat som Gmail får i Email Standards Projects undersökningar, resultaten stämmer förvisso eftersom klienten inte hanterar inbäddad CSS men i övrigt hanterar de allra flesta egenskaper alldeles utmärkt. Syftet med projektet är ju dock i första hand att föra en dialog och påpeka klienternas brister och med det i åtanke känns det lättare att acceptera resultatet och sågningen. Något som också bör vägas in vid bedömning av resultatet är den avgränsning som gjorts vad gäller testandet. Redan i början av arbetet specificerades vilka emailklienter som arbetet skulle rikta in sig på, vissa versioner och klienter har därmed medvetet utelämnats. Vid intresse är detta absolut något som rekommenderas som framtida utveckling, jag ser gärna att även en undersökning görs specifikt för mobila enheter. Det förslag jag tagit fram utifrån resultaten från test- och exempelmailen är inte en ren DIV -layout eftersom detta bevisligen inte fungerar men inte heller en helt tabellbaserad variant. I ett vanligt emaildokument skulle flera olika tabeller behöva användas och nästlas med rader och celler åt alla håll och det skulle inte bli någon rolig kod att arbeta med om man manuellt måste gå in och göra någon ändring, till exempel. Dokumenten skulle även bli oerhört tunga och stora med både massiva tabellkonstruktioner och inline CSS. Enligt gällande webbstandarder är det dessutom okej att placera till exempel en DIV -tagg inom en tabellcell vilket gör att mitt förslag även känns berättigat. 6.1.1.1 Praktisk lösning Hur skulle detta kunna användas rent praktiskt? 35

I samband med testmail 5 och exempelmail 2 började en bild av ett rent praktiskt användande av koden växa fram. I en annan applikation än HEJO MAIL som man utvecklat på HEJO Interactive använder man sig av en funktion med modultänk, det vill säga man bygger i det fallet en nyhetssida med hjälp av olika block som sedan kan flyttas upp eller ner beroende på önskemål. Detta var något jag fastnade för och såg potentiell användning i. Funktionen skulle givetvis kräva en del omstrukturering men jag ser ändå viss återanvändning vilket skulle spara tid och energi för framtida utvecklare. Tanken är alltså att man med hjälp av olika DIV -taggar skapar olika block i sitt emaildokument. Användaren kan givetvis själv välja hur stort ett block ska vara och måhända endast skapa bara ett block för hela sitt dokument men jag tror ändå att det kommer underlätta utformningen och framförallt hantering och placering av bilder. Ett förslag är att man skulle kunna behöva välja mellan text- och bildblock. Väljer man ett textblock måste man specificera ett teckensnitt, placering av både blocket och texten (vänster, mitten eller höger) och även en textstorlek som sedan alltså kommer gälla för hela det blocket. När man gjort dessa val får man upp en dialogruta där man kan klistra in sin text och därefter ska det kunna vara möjligt att fetlägga enstaka ord eller färglägga enstaka ord eller meningar. Detta görs rent tekniskt med hjälp av SPAN -taggar och inline CSS. I textblocken ska man även kunna infoga rubriker och länkar. Föråldrade taggar, såsom FONT - eller STRONG -taggar, bör undvikas för att eftersträva god webbstandard och eftersom det enligt testerna är möjligt att använda CSS för samma effekt. Funktionen för att infoga bilder är inaktiverad vid val av textblock och textinmatning eftersom särskilda val kommer behöva göras för dessa block. Som ett första steg måste man bestämma om man vill ha en fristående bild eller om man vill ha text flytande omkring den. Vid val av fristående bild kommer blocket således endast bestå av en DIV -tagg innehållandes en enda IMG -tagg. Attributen width och height bör anges för bilden eftersom detta ger ett säkrare resultat, är användaren inte så insatt skulle det kunna finnas ett val för att använda bildens originalstorlek till exempel. Även alt -attributet bör vara obligatoriskt för att öka tillgängligheten för bilden. Vid val av bild med flytande text föreslår jag i första hand två alternativ vad gäller placering; höger eller vänster, eftersom detta kommer att göras med hjälp av en tvåcellig tabell. När valet av placering är gjort får användaren infoga sin bild som därefter placeras i cell efter användarens val och texten får sedan klistras in via 36