Collecting the Internet So You Don't Have To

We work on the Internet. As such, we are constantly consuming information. Believe me, there is a lot of it out there. Sometimes we even forget things unless we write them down. Our blog covers everything from web standards to the muppets, php to comic books, music and everything else that we find interesting. Leave us a note when you drop by.

Email Templates: Making it Work for Outlook

Functionality
Ross McDowall
Ross McDowall Senior Web Developer
Visual Lizard
work
1 (204) 957-5520 ext:151
toll-free
1 (888) 237-9559
url
http://www.visuallizard.com
Ross McDowall Fearless Dwarven Warrior

In the past few years we've written a few articles about Email Templates and Email HTML standards. The reason we wrote these articles was because we have been doing a number of these email templates using various services like our emediatemail.com, MailChimp and others. In recent weeks we received a template design which should have been relatively straight-forward...

This particular design used background images in a few locations to enhance the look of the template. Normally we can display background images and then fallback to solid colours when the email client does not support them. In this case however it was extremely important to the client to have the background graphics appear in Outlook.

Outlook does not fully accommodate web or email standards. It will normally just fall back to a simpler version without background graphics. However, in order to solve this issue we are re-evaluating how we tackle these HTML email templates.

We decided to go back to the drawing table... literally. We went way back to how we used to layout HTML pages in the late 90s... tables and nested tables. Some googling for insight was also required.

Here are some of the things we learned:

Padding and margins - depending on which version of Outlook, css padding and margin may only be partially or not supported for block elements. We had to fallback to using the cellpadding attribute for Outlook. Unfortunately, this only works if you want a consistent padding around the content in the cells of a table. If you need some additional spacing or padding it's back to nested tables and cells containing the good old spacer graphic (transparent gif or png).

Because padding and margin on block level elements like paragraphs and headings aren't likely to work the way you intend them, the use of spacer graphics becomes important. The problem there is if spacers are applied around elements in these editable templates that are considered optional. For instance, the article in the template has an optional image between the heading and the first paragraph. The design has significant spacing between the heading, the image, and the paragraph that follows. Because we need the spacer graphics to help in the image positioning those spacers are always there. If the new version of the email newsletter our send-out doesn't require that image we are still left with the spacers which leaves a substantial space between the heading and the paragraph. Because of the lack of standards and Outlook's quirky interpretation of HTML we are stuck with some display oddities which we could not fully solve. Luckily they were acceptable to the client.

CSS float - again depending on which version of Outlook the email is being viewed in the level of support varies so it is best to find alternatives to floating elements. The best way to handle these layout issues is nested tables. If you need graphical elements to line up and be spaced properly then it's best to slice up the design graphic and set the table cells that contain those graphics to have no cellpadding or cellspacing. Sadly the old vspace and hspace attributes don't work. Older versions of Outlook might support them, but Outlook 2010 and 2013 don't.

Background images - the general practice out there to design your html email with background images that can't be left out of the display. Outlook will likely ignore them. We hate having to tell client's that we can't or couldn't achieve something. So if they want a background image in their HTML emails, we should do our best to accommodate. Unfortunately due to the still (it is 2014 Microsoft) non-standard HTML rendering in email clients, certain things like background images become really iffy to implement reliably.

For most email client browsers this isn't really an issue anymore as many of these are beginning to adopt some HTML standards. MS Outlook is not one of them. Microsoft has instead promoted the use of proprietary code in order to implement background images. The use of VML to implement backgrounds is their answer to the background image issue. This however is only the first part of their implementation. My colleague and I had to do some digging to find out why our VML implementation was still partially broken. Apparently any images that are to be implemented using this VML coding must be 96 dpi, not the default 72 dpi which most people know to use for web related imagery. The dimensions themselves don't change, but VML requires the 96 dpi. To be on the safe side it is best to make all images for the email template at that 96 dpi, even the ones that are not meant for backgrounds.

It should also be noted that this VML solution is not complete until the table inside the associated v:shape element is set with some negative margin to compensate for the VML inset. We couldn't find anywhere in our research for nullifying that inset, so our only solution was to include some MSO specific comments in our HTML which would allow us to reposition the element with CSS. Obviously this isn't ideal as mentioned above CSS isn't reliable in Outlook.

Other notes about email

Conclusion

When implementing an email template, always build for Outlook first. Once the hard stuff is done, minor tweaks to the CSS for web standard compliant browsers should be relatively straight-forward... maybe. As a note to designers, HTML email templates are a cool way to help with client marketing, we just would like you to keep in mind that there are some real limitations to what email client browsers can render. We as programmers don't like saying no because it would be awesome if we could do all of the things that your concepts entail. We just need to remind you that the technology hasn't necessarily caught up with that awesomeness.