Problems with designing HTML emails for Outlook?
It's Not You, It's Outlook!
Let’s talk about Outlook, Microsoft’s venerable (and much loved) email client. It is fair to say that it has a pretty steady grip on the email inboxes of much of the world, probably due in no small part to Microsoft’s prevalence in the enterprise sector (and, being bundled with MS Office).
If your subscribers sit in an office somewhere, they’re very likely to use it. Considering it’s been around at least since 1997, Microsoft has had plenty of time to improve its product, and by many measures has done so.
HTML RENDERING IN OUTLOOK STINKS
However, and this is a big one given Outlooks purpose, HTML rendering in Outlook stinks. Outlook 2003 uses Internet Explorer 6 to render HTML, which is pretty bad by modern standards.
As if that wasn’t bad enough, Outlook 2007 & 2010 render HTML using Word (yes, the word processor), which is an oil-tanker of offal come to dump its cargo full of torment on your day. If you’re an email marketer, email designer, or find yourself in the B2B client space, you’ve probably encountered some form of Outlook error. Your email looks pristine on your shiny iPhone, Android device, or web-based email client, (and most other email clients) but suddenly blows up when you open it up in Outlook. Yep been there, lets see if we can’t help resolve some of the headaches.
Firstly a couple of provisos.
- First, this article is for intermediate to advanced coders. You should be able to write and read HTML without a graphic interface to help you.
- Second, if you’re in the B2C space, or have a younger audience not privy to the whims of a corporate software buyer, you may be safe. At some point, the reward for investing the time designing and coding an email to beat Outlook’s messy rendering doesn’t pay off. If 1% of your client base is going to get a slightly less than optimal user experience for the extra 6 hours of work, you may find it worthwhile it to ignore Outlook entirely.
Now that we’ve cleared that up, let’s move on to the good stuff.
THINGS OUTLOOK DOESN’T SUPPORT
Put simply, Outlook won’t display them at all. If you use a repeating background image, keep it fairly simple and apply a background color as a backup. This is essential to keep HTML text displaying legibly.
Outlook will freeze an animated .gif on its first frame. (A shame I know). So keep it safe and avoind animated gif’s if you can or if it must be make sure the first frame is relevant.
CSS code displayed with the <head> tag can display erratically or not-at-all in many email clients, but it’s particularly nasty in Outlook. Keep your CSS styling in-line.
BUGS AND ERRORS
There are a number of bugs and errors in Outlook, and new ones are encountered with some frequency. So while these are by no means all of Outlook’s bugs, here’s a look at Outlook’s greatest (or worst)
- The Padding-Top Bug:
Padding-top will be applied to all <td> tags in a row, even if you only apply it to one <td>. There are several workarounds that come to mind. The easiest fix, in my mind, is to eschew using top padding on a row and add margin to elements contained within table cells to control the space between the element and the top of the table cell. Be careful to write the margin shorthand (margin: 0 0 0 0) instead of long hand (margin-top: 0px). In the latter case, you risk encountering a Hotmail bug. You can also add a one-cell nested table, and add padding-top to that. But that seems a bit inelegant.
- The 1,800 Pixel Bug:
If you create long emails, like a large quarterly newsletter, Outlook can break your email at around 1800 pixels. Remember when we mentioned that Outlook 2007 and 2010 render using Word? In this case, Outlook is treating your email as multi-page word processor document, and is adding page breaks. Surprise!
- Table-Cell Bug:
For table-cells with images shorter than 12px, be sure to apply height to them or face Outlook’s wrath. Sidenote: I hope you’re specifying your table cell height as often as you need to anyway.
- Adding Strokes to Tables:
If you add a stroke to a table that contains other elements, Outlook can add extra space/padding. In general, be very careful when using strokes on table elements.
- Line Heights:
Outlook can have issues with line heights, specifically if you like to specify line-heights using a number like 1.3. When you set that number to a less than one, Outlook will crop your typography in odd ways. You can find a nice guide for line height reference here.
[button url=”http://reference.sitepoint.com/css/line-height” main_color_number=”1″ type=”normal” target=”_blank”] More about line height [/button]
[divider before=”25px” after=”20px”]
If you’ve read all the way down here, you may be a bit depressed by now. On the other hand, if you’ve been coding emails for a bit, you’ve probably internalized your rage and learned to expect the worst. The solution, simply, is to test, test, and test again. Testing for rendering issues is the only way to make sure your emails render consistently. Always send a test email to an inbox running Outlook.
The second solution is to fill your emails with useful content. Get feedback from your customers on what kinds of messages they want to read and email accordingly. Ultimately, useful content will trump a few graphic discrepancies any day of the week.
Read Microsoft’s guide to CSS support in Outlook 2007. The best part of this guide may be the comments section, where email designers have contributed a litany of woes.