HTML integration in different email clients

Today, we are going to go into the details of designing the HTML file of an email. The most difficult part of this work is to have the desired rendering in all a maximum of email clients. Web pages are displayed by a browser (Internet Explorer, Firefox, Chrome, ...) and, since the updates of Internet Explorer, browsers are starting to be more or less in line with the W3C, the organization that defines web development standards. For an email, it can be displayed either in an email client application (Outlook, Apple Mail, ...) which will interpret the code to its liking, or in a web email client, in which case the code will be interpreted twice: once by the browser, as a web page, a second time by the email client (Gmail, Outlook.com, ...).
All the complications come from the interpretation of the code by these email clients.

So 90's

The first difficulty comes from email client applications. If most companies try to keep their client applications up to date, some users have quite old email clients (Outlook 2010, Lotus Notes, ... ). Especially in some B2B environments, where updates of these software are always postponed due to the complexity to be done on their entire network.

That's why emailing developers code with HTML that dates back to the 90's, which is not very efficient in terms of reading and simplifying the code and has little to do with good web development practices, but is robust in many environments. Modern web page design techniques do not work in most of these email clients (rounded edges, background images, ...). To be precise, it is especially Outlook that causes problems for integrators. For some dark reason, the HTML rendering engine of the latest versions of Outlook is the HTML rendering engine of... Word! And this one is not at all up to date with the W3C recommendations. By chance, or maybe voluntarily from Microsoft in order to offer a "work-around", there is specific code for this renderer, the vml (you can read our article on this subject), which allows to get around some problems. On the other hand, this makes the code more complex, and less accessible to the layman.

Apart from Outlook, if you work with some big companies that haven't updated their emailing park for a (very) long time, you can be confronted with the nightmare of any integrator: Lotus 6.5 and 7. These email clients are becoming very rare, but they are still important in some cases. And these email clients are particularly twisted in their interpretation of HTML code. If this is your case, you don't need a very complicated design to hope to keep a correct rendering.

Let's do it again

The second difficulty comes from the web email clients. For these, you must first get a correct rendering with the interpretation of the code of the different browsers, and then a correct rendering with the interpretation of the code of the email clients themselves. These add an extra layer of code to the HTML code of an email. Some of them specify line spacing values that you will have to override (Outlook.com), others only take into account the centering of an element if it is specified in a certain way (Yahoo) or, as we have developed in a previous articlethe specific code for mobile display is not taken into account (Gmail).

And this is where the difficulty of integration comes in. If it is easy to get a correct rendering in a specific email client, it is quite complicated to get a correct rendering in a maximum of email clients, some code bits being interpreted differently. Let's take the example of a padding on a fixed width block. In some cases the padding value will be included in the width, in others it will be added to the width, which makes it an attribute to avoid since the rendering will be different in different email clients. There are many cases where pieces of code that avoid the difficulties of one email client result in a bad rendering on another email client.

A false friend that used to be commonly used is to cut your email into images. It is then very easy to keep the design identical on all email clients since it is no longer the HTML code that generates the design, but one or more images.
If for a while this influenced the spam score of the email, this seems to be less the case today. On the other hand, the vast majority of email clients disable images by default. And users are exposed to more and more communication. The message to be transmitted must therefore be clear at a glance. If to display your email you have to go through a first click to display the images, then you have already lost a part of your audience.

Priorities

Having a perfect rendering in all email clients is impossible. The first reason being that it is, in practice, unthinkable to test all email environments (depending on the OS, the browser, the application); it is however possible to test on the overwhelming majority of cases. It is also possible to verify after a few sendings which are the majority email clients used by your targets. This allows you to focus your efforts in a precise and relevant way.

Badsender can accompany you in the creation of your emails and accompany you in the implementation of tests and good practices. Do not hesitate to consult our agency site or contact us for more information!