E-mailkodning vs. webkodning: Hvad er forskellen?
Kristina Lauren
25. august 2021
Du har bygget en hjemmeside, men nu skal du opbygge en e-mailadresse
Lad os sige, at du har lidt erfaring med kodning med HTML, CSS og JavaScript, og du gerne vil give din første e-mail en chance.
Selvfølgelig forventer du, at design af en e-mail er noget anderledes end udvikling til webbrowsere, men du vil måske blive overrasket over at erfare, at nogle af de grundlæggende værktøjer og elementer, du bruger til at kode til internettet, ikke altid er tilgængelige til udvikling af e-mails.
Derfor vil vi i denne artikel se på nogle vigtige forskelle mellem kodning til nettet og kodning til e-mail.
En oversigt over forskellene mellem webudvikling og e-mailudvikling.
Lad os tale om standarder
Webudvikling er ret standardiseret, men det skete ikke bare af sig selv. De tidlige dage med internettet var kaotiske – webbrowsere skabte vidt forskellige metoder til at gengive kode, hvilket tvang udviklere til at oprette flere versioner af et websted for at sikre, at det gengiv korrekt i hver browser. Udviklere blev forståeligt nok frustrerede over dette, hvilket førte til World Wide Web-konsortiet udarbejdede retningslinjer for webkodning og -gengivelse i starten af 2000'erne. Disse standarder gav ikke kun udviklere et ensartet sæt kodningsregler, men de skabte også en mere ensartet oplevelse for brugere af internettet, som alle nyder godt af i dag.
E-mail sidder derimod stort set stadig fast i starten af 2000'erne. På grund af mangel på officielle retningslinjer er e-mailklienter stort set frie til at gengive kode, som de vil. Det betyder varierende understøttelse af mange designelementer, ringe konsistens på tværs af e-mailplatforme og behovet for forskellige hacks bare for at få en enkelt e-mail til at gengives ensartet på tværs af web-, desktop- og mobilklienter.
Så hvordan påvirker dette stylingen?
Inden for webudvikling har du HTML, CSS og JavaScript lige ved hånden. Med CSS specifikt har du mulighed for at bruge inline styling eller at linke et eksternt stylesheet til HTML-filen. Sidstnævnte er typisk den bedste praksis, især når store mængder styling er nødvendige, fordi det at have en fil udelukkende dedikeret til CSS hjælper med at holde din kode pæn og pæn.
In email development, you can only use HTML and CSS. On top of this, some clients will remove internal styling in the
section, including any linked external CSS files, leaving your emails stripped bare with awkward formatting and no style.Derfor er den bedste fremgangsmåde at holde al CSS-styling integreret – i selve HTML-tagsene – for at sikre, at intet går tabt, uanset hvilken klient der gengiver din e-mail.
Der er også et par begrænsninger, hvad angår visse CSS-egenskaber. For eksempel understøttes display: none;, som også ofte bruges med JavaScript, ikke af alle e-mailklienter, så stol ikke på, at det skjuler designelementer for dine seere.
Trods CSS-begrænsninger kan du stadig style dine e-mails effektivt, det kræver bare lidt mere indsats og kreativitet.
Hvad med layoutet?
Inden for webudvikling får du masser af fleksibilitet, hvad angår layout. Med tilgængeligheden af div-elementer samt introduktionen af systemer som CSS Grid er positionering af elementer blevet meget mere kompliceret og endda nemmere end det var tidligere.
Men når det kommer til e-mail, er tabeller dine bedste venner. I mangel af div-elementer kan tabeller bruges til at justere indhold i forskellige retninger, indstille margen og polstring eller oprette knapper med klikbar tekst. Faktisk giver tabeller også en vis stabilisering, når det kommer til ordnede og uordnede lister.
og
Tags fungerer ikke korrekt med alle e-mailklienter. Nogle gange kan afstanden mellem punkterne være lidt forkert, eller punkterne kan mangle helt, men tabeller hjælper med at forhindre dette ved at holde alt sammen.
Når du begynder at kode, vil du bemærke nødvendigheden af indlejring – at bygge tabeller inden i tabeller. Du skal dog være forsigtig med ikke at komplicere dit layout med for meget indlejring. Det er nemt at lave dumme fejl, når du har at gøre med en masse tabeller – du kan ved et uheld indsætte en tabel et sted, hvor den ikke hører hjemme, eller glemme at rette et andet vigtigt stykke HTML, hvis du er nødt til at flytte rundt på en af tabellerne. Nogle klienter kan også klodset gengive din e-mail, hvis dine tabeller er indlejret for dybt. For at undgå dette skal du prøve at holde dig til højst 5 tabeller.
Hvordan kan billeder og videoer integreres i e-mails?
Brug af en eller anden form for grafik i din e-mail kan virke som den bedste måde at fange dine abonnenters opmærksomhed på, men du kan ikke altid regne med, at visuelle elementer formidler dit budskab fuldt ud. Som standard blokerer mange e-mailklienter billeder, og nogle af dine abonnenter – enten på grund af præference eller manglende viden – har muligvis automatisk billedindlæsning slået fra. For at forhindre, at dine abonnenter bliver helt uvidende i denne situation, skal du bruge alt-tekst sammen med din grafik. Hvis intet indlæses, vil dine læsere stadig have en generel idé om, hvad det visuelle skal være.
Så hvad med videoer? Som du sikkert har gættet, understøttes disse heller ikke af de fleste klienter, men der er en smart løsning på dette problem. Hvis du er interesseret i at vise videoer i dine e-mails, kan du blot bruge et foto, placere et afspilningsknapikon på fotoet og integrere et link i grafikken. Når e-mail-seere derefter klikker på "videoen" for at afspille den, bliver de omdirigeret til en webbrowser, hvor den faktiske video afspilles.
En anden mulighed, vi anbefaler, er at bruge gifs. Du kan konvertere din video til en gif og indsætte den i e-mailen, så seerne i det mindste kan se videoens visuelle elementer uden at blive omdirigeret. Grafikkens bevægelse vil ikke kun fange seernes opmærksomhed, men kan også hjælpe med at holde deres opmærksomhed fanget i længere tid.
Hvilke skrifttyper understøttes i e-mails?
Vi har talt om skrifttyper et par gange på vores blog nu og lagt vægt på vigtigheden af at vælge skrifttyper, der er sikre til e-mail Da du muligvis ikke har kontrol over, hvordan forskellige e-mailklienter viser din tekst, bør du vælge en skrifttype, som langt de fleste kunder har på lager, såsom Arial eller Helvetica. Selvom disse almindelige skrifttyper måske ikke afspejler dit brand perfekt, som mere unikke skrifttyper ville, bør du stadig være i gode hænder, så længe du bruger den samme e-mailvenlige skrifttype konsekvent i alle dine kampagner.
If the idea of an email-safe font isn’t appealing, you also have the option of using a resource like Google Fonts, which will provide you with code for a plethora of font families that you can copy and paste into the
section of your HTML file. But remember, some email clients will strip this section of the file, leaving your text at the mercy of whatever fonts your subscribers’ email clients decide on. To be safe, you should always include a fallback font within your inline CSS.Konklusion
Det kan være chokerende at lære, hvor mange forskelle der er mellem web- og e-mailudvikling, men det betyder ikke, at du stadig ikke kan producere nogle fantastiske e-mails til dit publikum. Der findes en masse tricks og hacks, du kan bruge til at få det perfekte e-maildesign – vi gennemgår faktisk nogle meget nyttige i en af vores artikler, der fokuserer på opbygning af e-mails fra bunden Hvis du foretrækker at bruge en skabelon, der allerede er udviklet af vores ekspertteam, kan du se mere på Tiramisu-appen at komme i gang.