Im modernen Zeitalter des Smartphones sollte man meinen, dass ein gescheites responsives Layout herauskommt, wenn man sich an die Web Standards hält. Natürlich muss man den einen oder anderen Trick anwenden, um die Darstellung für alle Browser – womöglich noch für alte Versionen wie z. B. den Internet Explorer 9 – anzupassen, aber solche Lösungen gehören ja mittlerweile zum Tagesgeschäft eines Web-Entwicklers.
Bei der Anpassung der Email-Templates im OXID eShop eines unserer Kunden wurde uns diese Vorstellung sehr schnell ausgetrieben. Wir hatten das Email-Debugging Tool in OXID benutzt, um eine erste Version im Browser zu bauen, testeten die Email dann im Thunderbird und erlebten nach einem Test des Kunden unser blaues Wunder: in Microsoft Outlook sah das Design ziemlich zerschossen aus.
Was war das Problem?
Kurz gefasst: nach einer Entscheidung von Microsoft verwendet Outlook seit der Version 2007 Microsoft Word als seine HTML Rendering Engine. Ja, richtig gelesen: WORD. Diese Entscheidung führt dazu, dass sich Entwickler von vielen modernen Features von HTML und CSS verabschieden dürfen. Grob gesagt ist man auf die Verwendung von HTML 4 und CSS 1 beschränkt. Campaign Monitor hat dazu eine recht gute Übersicht: (Link: https://www.campaignmonitor.com/css/email-client/outlook-2007-16/) Die Struktur der Email basierte bereits auf Tabellen, die allerdings bereits mittels CSS-Klassen gestyled waren. Dies warf die ersten Probleme auf, da CSS-Klassen bzw. die Einbindung über >link> bzw. >style> Tags bereits problematisch ist. Um die Darstellung auch auf kleineren Viewports zu gewährleisten hatten wir einige Styles responsiv angelegt und über einen Media Query für größere Viewports überschrieben. Hallo Outlook, Good Bye Media Queries! Wie man in der Übersicht von Campaign Monitor sehen kann, versteht Outlook keines der gängigen Media Query Anweisungen. Kleinere Probleme machte das Design an sich: da Outlook ein Problem mit der Einbindung von Hintergründen und Bildern hat, musste das erste Screendesign des Kunden dahingehend angepasst werden, dass z. B. keine Hintergrundverläufe verwendet wurden. Ein letztes Problem, welches aber nicht mit der verwendeten Technik zusammenhängt, ist Dokumentation. Bei der Suche nach einer Lösung fanden wir relativ viele Blog-Beiträge, die jedoch meist mehrere Jahre alt waren (2012 und davor). Verwiesen diese Beiträge dann noch auf eine Microsoft-Seite konnte man sich sehr sicher sein, dass nach der Zeit die Seite nicht mehr verfügbar war und man unweigerlich in einem Irrgarten an Redirects gestrandet war. Einige gute Quellen haben wir unten aufgelistet.
Wie wurde das Problem gelöst?
Das Vorgehen war, auf Basis der von uns gefundenen Resourcen, weitgehend wie folgt:
- Bereite die Struktur mithilfe von einfachen HTML-Tabellen vor.
- Verwende so weit es geht Attribute, um Ausrichtung, Abstände und andere Design-Angaben vorzubereiten.
- Reichere die fertige Struktur mittels Inline-Styles an und passe so die Struktur weiter an das Design an.
Auch wenn jetzt der ein oder andere kalte Schauer spürt: ja, Inline-Styles sind leider das einzige Mittel, CSS verlässlich in Email-Templates für Outlook einzubauen. Selbst Libraries wie MJML lassen hinterher die Styles als Inline-Anweisung in die Email fliessen.
Testen, testen und testen!
Es wurde teilweise eine Test-Email geschickt, nur weil ein Innenabstand eines Elementes zu überprüfen war. Hintergrund war der, dass das Element den Abstand nicht berücksichtigt hatte und man gezwungen war, eine zusätzliche Tabelle um das Element zu legen.
Wie kann man zukünftig solche Probleme vermeiden?!
Wenn man unbedingt ein eigenes Template verwenden möchte oder muss, so würden wir folgende Empfehlungen geben:
Das oben genannte Vorgehen ist zwar etwas müßig, bietet aber die Sicherheit, jederzeit recht schnell Fehlersuche betreiben zu können. Also erst die HTML-Struktur bauen, dann Inline-CSS nachziehen und testen.
Unser persönlicher Favorit ist noch KISS: Keep It Simple, Stupid. Am besten verzichtet man auf aufwendige, ineinander verschachtelte Designs mit zu vielen Features. Manchmal ist weniger mehr!
Wenn man auf aufwendige Designs nicht verzichten kann oder will, so gibt es in einigen CSS-Frameworks bereits fertige Email-Templates und Styles, z. B. bei Zurb Foundation. Hier entfällt der größte Teil des Test-Aufwands, allerdings muss man die entsprechenden Libraries in den OXID Shop integrieren.
Eine Alternative zu selbst gebauten Templates (und dem damit verbundenen Test-Aufwand) sind natürlich noch die zahlreich verfügbaren Email-Templates namhafter Anbieter, z. B. Inxmail. Der Nachteil sind hier natürlich die Kosten, die pro Email anfallen können. Die Integration in OXID eShops ist dank vorhandener Schnittstellen entsprechend einfach.
Quellen:
https://www.campaignmonitor.com/css/
https://www.smashingmagazine.com/search/?q=html email
https://www.sitepoint.com/how-to-code-html-email-newsletters/
