In het moderne tijdperk van de smartphone zou je denken dat er een fatsoenlijke responsieve lay-out uitkomt als je je aan de webstandaarden houdt. Natuurlijk moet men een of andere truc gebruiken om de weergave voor alle browsers aan te passen - mogelijk zelfs voor oude versies zoals Internet Explorer 9 - maar dergelijke oplossingen behoren nu tot de dagelijkse werkzaamheden van een webontwikkelaar.
Bij het aanpassen van de e-mailtemplates in de OXID eShop van een van onze klanten werd dit idee heel snel weggenomen. We hadden de e-mail debugging tool in OXID gebruikt om een eerste versie in de browser te bouwen, vervolgens de e-mail in Thunderbird getest en na een test door de klant ons blauwe wonder ervaren: in Microsoft Outlook zag het ontwerp er behoorlijk geschoten uit.
Wat was het probleem?
In een notendop: na een beslissing van Microsoft gebruikt Outlook sinds versie 2007 Microsoft Word als HTML-rendering engine. Ja, lees dat goed: WOORD. Dit besluit betekent dat ontwikkelaars afscheid moeten nemen van veel moderne functies van HTML en CSS. Grofweg bent u beperkt tot het gebruik van HTML 4 en CSS 1. Campaign Monitor heeft hier een goed overzicht van: (Link: https://www.campaignmonitor.com/css/email-client/outlook-2007-16/) De structuur van de e-mail was al gebaseerd op tabellen, maar deze waren al gestyled met behulp van CSS-klassen. Dit veroorzaakte de eerste problemen, aangezien CSS-klassen en de integratie ervan via >link> en >style> tags al problematisch zijn. Om de weergave op kleinere viewports te garanderen, hadden we sommige stijlen responsief gemaakt en via een media query overschreven voor grotere viewports. Hallo Outlook, Dag Media Queries! Zoals u kunt zien in het overzicht van Campaign Monitor, begrijpt Outlook geen van de gangbare media query instructies. Kleinere problemen werden veroorzaakt door het ontwerp zelf: aangezien Outlook een probleem heeft met de integratie van achtergronden en afbeeldingen, moest het eerste schermontwerp van de klant worden aangepast, zodat bijvoorbeeld geen achtergrondverlopen werden gebruikt. Een laatste probleem, dat geen verband houdt met de gebruikte technologie, is de documentatie. Bij het zoeken naar een oplossing vonden we een relatief groot aantal blogberichten, waarvan de meeste enkele jaren oud waren (2012 en eerder). Als deze berichten toen nog verwezen naar een Microsoft-pagina, kon je er heel zeker van zijn dat die pagina na die tijd niet meer beschikbaar was en je onvermijdelijk strandde in een doolhof van redirects. We hebben hieronder enkele goede bronnen opgesomd.
Hoe is het probleem opgelost?
De procedure, gebaseerd op de door ons gevonden middelen, was grotendeels als volgt:
- Bereid de structuur voor met eenvoudige HTML-tabellen.
- Gebruik zoveel mogelijk attributen om uitlijning, afstand en andere ontwerpspecificaties voor te bereiden.
- Verrijk de afgewerkte structuur met inline stijlen om de structuur verder aan te passen aan het ontwerp.
Zelfs als sommigen van u nu koude rillingen krijgen: ja, inline stijlen zijn helaas de enige manier om betrouwbaar CSS te integreren in e-mailsjablonen voor Outlook. Zelfs bibliotheken als MJML laten de stijlen achteraf in de e-mail vloeien als inline statements.
Test, test en test!
Soms werd een testmail verstuurd, alleen omdat een binnenruimte van een element moest worden gecontroleerd. De achtergrond was dat het element geen rekening had gehouden met de tussenruimte en men gedwongen was een extra tabel om het element heen te zetten.
Hoe kunt u dergelijke problemen in de toekomst voorkomen?!
Als u absoluut uw eigen sjabloon moet of wilt gebruiken, raden wij u het volgende aan:
De bovenstaande procedure is enigszins inactief, maar biedt de zekerheid dat problemen op elk moment snel kunnen worden opgelost. Bouw dus eerst de HTML-structuur, voeg dan inline CSS toe en test.
Onze persoonlijke favoriet is nog steeds KISS: Keep It Simple, Stupid. Het beste is om uitgebreide, geneste ontwerpen met te veel functies te vermijden. Soms is minder meer!
Als u niet zonder uitgebreide ontwerpen kunt of wilt, zijn er al kant-en-klare e-mailsjablonen en -stijlen in sommige CSS-frameworks, bijvoorbeeld Zurb Foundation. Hier vervalt het meeste testwerk, maar u moet wel de bijbehorende bibliotheken in de OXID-winkel integreren.
Een alternatief voor zelfgemaakte sjablonen (en de bijbehorende testinspanning) zijn natuurlijk de talrijke e-mailtemplates van bekende aanbieders, zoals Inxmail. Het nadeel is natuurlijk de kostprijs per e-mail. Integratie in OXID eShops is dienovereenkomstig eenvoudig dankzij de bestaande interfaces.
Bronnen:
https://www.campaignmonitor.com/css/
https://www.smashingmagazine.com/search/?q=html e-mail
https://www.sitepoint.com/how-to-code-html-email-newsletters/
