Coding newsletters for Outlook

2017 is a great year for being a web developer. In the recent years we received great new tools and long-awaited updates to many established ones. Think of ES6/ES7, React/Angular or Node.JS. Therefore coding small HTML e-mail template should be a view to easy, boring work. Not so elementary, my dear Watson.

Microsoft strikes back

This article is not aimed to ridicule the Redmond giant. Million of words have already described the pain which was/is related to their products. Don’t get me wrong, most of their the products are industry leading. But every now and then dice is rolled. Sometimes it backfires. Sadly, them being one of the biggest technological companies, these decisions can cause some serious headaches all around the developer community. (Yes, I’m looking at -you, Internet Explorer).

Now, with IE out of the way, everything is fine? Well…no. If we consider our browsers as mature, highly-developed pieces of software then e-mail clients are the true wild west. Guilt lies on both sides, vendors and web authorities were not able to agree upon any standard for displaying HTML content. Some took it seriously and utilised browser rendering engines whilst some just played it safe using either outdated rendering engines or even worse, tools that were not intended to display HTML in the first place.

HTML e-mails in 2017

The current way of building HTML e-mails is rather simple although painful. Forget about nth:child or .elem1 > .elem2. Sure, we can live without it, there will a lot of classes but we are not building an extensively sized app.

Sadly, it doesn’t stop there. When your customers don’t use cutting edge e-mail clients you can forget about stylesheets all together. Wait, what? Although Gmail recently started supporting (finally!) stylesheets and media queries there are still some lurking around with poor support.

Enough for the bad news, you might reply. It’s still recommended to use tables exclusively. Desktop Outlook, older versions of Thunderbird and others still can’t wrap their heads around div, let alone HTML5 elements.

What’s the fuss about Outlook?

First things first, currently various versions of desktop Outlook client account for roughly 7 percent of the market. Which might not be a lot but oftentimes you can’t afford to drop even that relatively small part of the market.

Secondly, ancient versions of desktop clients (up until 2003) used IE rendering engines (dependable on OS version), roughly lowest you could go was IE5, which is terribly outdated but most of the practices work there. Out of the blue, with the release of Office 2007 Microsoft decided to ditch the idea of using IE as a base for Outlook and rather opted for Word HTML rendering engine. If that gave you goosebumps you’re not alone. Not until Outlook 2016 and rise of outlook.com was it changed.

What we are going to build

With such vast variety of email clients I came across weird behaviour and glitches which I found solutions for therefore I could share it with the world.

Disclaimer: Even though it’s unlikely something will dramatically change, code example do work at the date of publishing (June 2017).

With the knowledge of the constrains that e-mail templates impose we can drive right in. Let say we want to build this simple footer for our newsletter.

Nothing fancy, right?

Custom fonts

A question immediately arises: How do I put custom fonts to an e-mail? (I know we should strive for least possible size and accessibility but let say our customer’s brand requires certain font to be used when communicating with outer world). Easy answer is to use images for text. I does work but size overhead is increased as well as probability of sending your e-mail straight into spam folder (as many providers use considerate amount of images as a red flag). Don’t forget we have @font-face at our disposal. I might not work everywhere but support among clients is pretty solid (https://www.campaignmonitor.com/resources/guides/web-fonts-in-email/), otherwise we display fallback font.

Note: Naturally there are other ways of using custom fonts, using import or link but @font-face gives you the most control (you get to choose which font formats to use) as well as it provides bullet-proof solution for supported clients.

Therefore we create stylesheet for fonts (or put its content directly to template), put font file onto our server (or use Google Fonts or alike). Easy, right? We’re almost there. Try to display your e-mail in Outlook. It doesn’t support custom fonts, all right, so let it display Arial or other sans-serif font instead. But that doesn’t look like it, isn’t that Times New Roman? Sure it is.

Times New Roman?

The most reasonable workaround is put the whole @font-face into conditional loading statement.

<!--[if !mso]><!-- -->  
@font-face {
font-family: 'yourfont';
src: url('yourfont.woff')format('woff');
font-weight: normal;
font-style: normal;
}
<!--<![endif]-->

This effectively says if you’re Outlook don’t even look at it hence when it reaches our snippet, it naturally won’t recognise the font so it skips to the next on, our correct fallback.

Not particularly the same but close enough.

Simple footer navigation

Second part of our footer is the navigation. We'll be using this as a base markup for our table as this goes straight into body element.

<table 
bgcolor="#46013f"
cellpadding="0"
cellspacing="0"
width="100%">
<tbody>
<tr>
<td align="center" style="padding: 65px 0px 65px 0px">
<table
align="center"
cellpadding="0"
cellspacing="0"
style="border-collapse:
collapse;"
width="600">

            ...our code...

</table>
</td>
</td>
</tbody>
</table>

This chart shows us approximate sizing of the whole thing as well as it illustrates the individual elements.

Sizing chart.

Approach #1

We'll start with the easiest way. Instead of trying to come up with clever solution for dividers we just throw in images.

Text with dividers exported as single images.
Note: I'll only show code for first item as it only differs in width.
<td style="width: 74px;">
<a href="/" style="
padding: 0 0 0 0;
color: #ffffff;
border: 0;
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 14px;
white-space: nowrap;
text-decoration: none">
ABOUT US
</a>
</td>
<td style="width: 36px; padding: 0 0 0 0;">
<img src="url-to-image" alt="" />
</td>

All of above gives us nicely looking footer. We could call it a day but unnecessary use of images is not what we're aiming for. Moreover considerable amout of HTTP requests is added as well as increased size of the whole thing might be a concern. As mentioned before, some e-mail clients see profound use of images as a hint of spam.

Well, it works but with unnecessary images

Approach #2

Ditching images should be a question of adding border-right to td wrapping our a with text.

Very simple idea indeed.

First item is nearly the same, note the border-right acting as a divider with no extra elements or hacks.

<td style="width: 74px; border-right: 2px solid #ff006c; padding: 0px 18px 0px 0px">
<a href="/" style="
padding: 0 0 0 0;
color: #ffffff;
border: 0;
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 14px;
white-space: nowrap;
text-decoration: none">
ABOUT US
</a>
</td>
<td style="width: 68px; border-right: 2px solid #ff006c; padding: 0px 20px 0px 18px;">
<a href="/" style="
padding: 0 0 0 0;
color: #ffffff;
border: 0;
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 14px;
white-space: nowrap;
text-decoration: none">
CONTACT
</a>
</td>

That should be it. Try it in Apple Mail, Gmail or even outlook.com. Works fine, right?

What the hell is this?

When you view it in Outlook 2007 you get this. That Word rendering engine we talked about earlier produces unexpected behaviour when you mix borders and padding. Oddly enough padding-left works as expected. There are numerous articles regarding this topic, sadly there's not ultimate solution to all this hassle.

Approach #3

After abandoning previous idea of not using any extra markup I opted for using an extra td.

<td style="width: 74px;">
<a href="/" style="
padding: 0 0 0 0;
color: #ffffff;
border: 0;
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 14px;
white-space: nowrap;
text-decoration: none">
ABOUT US
</a>
</td>
<td style="width: 36px; padding: 0 0 0 0;">
<table align="center"
cellpadding="0"
cellspacing="0"
style="border-collapse: collapse;"
width="36">
<tbody>
<tr>
<td style="
border-right: 2px solid #ff006c;"
width="18px">
</td>
     <td style="width="18px"></td>
</tr>
</tbody>
</table>
</td>

This works okay considering we add some text to our td in the nested table because outlook can't display empty cells even though they have styles applied. By adding for example nsbp; (non-breakable space) we solve this. But again I reckon we can do better.

Works…sort of.

Final solution

After some pondering (which shouldn't have happened in the first place since this must be 5 minute job not 3 hours of googling, testing and cursing) I finally found a solution I was content with. Idea of using border was dissmised for good with | as a replacement. This solved Outlook's unability to display empty cells as well as quirky border situation.

Use of “|” symbol as a divider.
<td style="width: 74px;">
<a href="/" style="
padding: 0 0 0 0;
color: #ffffff;
border: 0;
font-family: Arial, sans-serif;
font-weight: bold;
font-size: 14px;
white-space: nowrap;
text-decoration: none">
ABOUT US
</a>
</td>
<td style="width: 36px; padding: 0 0 0 0;">
<table align="center"
cellpadding="0"
cellspacing="0"
style="border-collapse: collapse;"
width="36">
<tbody>
<tr>
<td style="
padding: 0px 16px 0px 0px;
color: #ff006c;
text-align: right;"
width="20px">
|
</td>
</tr>
</tbody>
</table>
</td>

This works in every Outlook version I was able to test it on.

Finally!

Takeaways

After 1500 words and multiple images I hope I shed some light on seemingly trivial problems that don't seem so elementary after second look. This is multiplied by so many different version that need to be tested. Very useful tool I came across is Litmus.

The provide vast range of clients just with one click. It's not cheap by any means but it definitely saves a lot of headaches. As you can see, even using border and padding can prove out to be troublesome.

Never take seemingly basic things for granted!

Thanks for reading this! I seriously hope it's going to help you at lot 👊

You can follow me on Instagram, Twitter or visit my website.