In the modern age of the smartphone, you would think that a decent responsive layout would come out if you stick to the web standards. Of course, one has to use one or the other trick to adapt the display for all browsers - possibly even for old versions such as Internet Explorer 9 - but such solutions are now part of the daily business of a web developer.
When adapting the email templates in the OXID eShop of one of our customers, this idea was very quickly dispelled. We had used the email debugging tool in OXID to build a first version in the browser, then tested the email in Thunderbird and experienced our blue miracle after a test by the customer: in Microsoft Outlook the design looked pretty shot.
What was the problem?
In a nutshell: following a decision by Microsoft, Outlook has been using Microsoft Word as its HTML rendering engine since version 2007. Yes, read that right: WORD. This decision means that developers have to say goodbye to many modern features of HTML and CSS. Roughly speaking, you are limited to using HTML 4 and CSS 1. Campaign Monitor has a good overview of this: (Link: https://www.campaignmonitor.com/css/email-client/outlook-2007-16/) The structure of the email was already based on tables, but these were already styled using CSS classes. This caused the first problems, as CSS classes and their integration via >link> and >style> tags are already problematic. In order to guarantee the display on smaller viewports, we had created some styles responsively and overwritten them via a media query for larger viewports. Hello Outlook, Good Bye Media Queries! As you can see in the Campaign Monitor overview, Outlook does not understand any of the common media query instructions. Smaller problems were caused by the design itself: as Outlook has a problem with the integration of backgrounds and images, the client's first screen design had to be adapted so that, for example, no background gradients were used. A final problem, which is not related to the technology used, is documentation. When looking for a solution, we found a relatively large number of blog posts, most of which were several years old (2012 and before). If these posts then still referred to a Microsoft page, you could be very sure that after that time the page was no longer available and you were inevitably stranded in a maze of redirects. We have listed some good sources below.
How was the problem solved?
The procedure, based on the resources we found, was largely as follows:
- Prepare the structure using simple HTML tables.
- Use attributes as far as possible to prepare alignment, spacing and other design specifications.
- Enrich the finished structure with inline styles to further adapt the structure to the design.
Even if some of you feel cold shivers now: yes, inline styles are unfortunately the only means of reliably incorporating CSS into email templates for Outlook. Even libraries like MJML let the styles flow into the email as inline statements afterwards.
Test, test and test!
Sometimes a test email was sent just because an inner space of an element had to be checked. The background was that the element had not taken the spacing into account and one was forced to put an additional table around the element.
How can you avoid such problems in the future?!
If you absolutely have to or want to use your own template, we would recommend the following:
The above procedure is somewhat idle, but it offers the security of being able to troubleshoot quite quickly at any time. So first build the HTML structure, then add inline CSS and test.
Our personal favourite is still KISS: Keep It Simple, Stupid. It's best to avoid elaborate, nested designs with too many features. Sometimes less is more!
If you can't or don't want to do without elaborate designs, there are already ready-made email templates and styles in some CSS frameworks, e.g. Zurb Foundation. Here, most of the testing effort is omitted, but you have to integrate the corresponding libraries into the OXID shop.
An alternative to self-built templates (and the associated testing effort) are of course the numerous email templates available from well-known providers, e.g. Inxmail. The disadvantage here is, of course, the cost per email. Integration into OXID eShops is correspondingly simple thanks to existing interfaces.
Sources:
https://www.campaignmonitor.com/css/
https://www.smashingmagazine.com/search/?q=html email
https://www.sitepoint.com/how-to-code-html-email-newsletters/
