The Techie Side of Email CampaignsOctober 24, 2011


There are some facts for those of you new to HTML., Keep it simple. The more complex your email design, the more likely it'll get tossed into spam or even lost in translation. Different email users have different viewing software. Just because a template looks nice in Outlook, doesn’t mean it will look good in Yahoo Mail.

Tables Should be used for the layout


Because clients like Gmail and Outlook 2007 have poor support for  margin, float, and padding, you’ll need to use tables as the framework of your email. Although nested tables are supported, consistent treatment of width, margin and padding within table cells is not. For the best results, keep the following in mind when coding your table structure.

Set the width in each cell, not the table


If you combine table widths, td widths, td padding and CSS padding into an email, the final result is different in almost every email client. The most reliable way to set the width of your table is to set a width for each cell, not for the table itself.
<table cellspacing="0" cellpadding="10" border="0"> <tr> <td width="80"></td> <td width="280"></td> </tr> </table>

Never assume that an unspecified cell width will be figured out out by the client's email. It absolutely will not.  Also, make sure to avoid using percentage based widths. Clients with different Outlook version don’t respect them, especially for nested tables. Using pixels is your best bet here. Feel like adding padding to each cell, use either the cellpadding attribute of the table or CSS padding for each cell, but never combine them.

Err toward nesting


Table nesting is more reliable than setting margins or padding for table cells. If you can achieve the same effect by table nesting, that will always give you the best result across the various email clients.

Use a container table for body background colors


Some email clients ignore background colors specified in your CSS or the <body> tag. Want to go around this? wWrap your entire email with a 100% width table and give that a background color.
<table cellspacing="0" cellpadding="0" border="0" width="100%"> <tr> <td bgcolor=”#000000”> Email code goes here. </td> </tr> </table>

You can use the same approach for background images too. Just remember that some email clients don’t support them, so always provide a fallback color.

Avoid unnecessary whitespace in table cells


Where possible, avoid whitespace between your <td> tags. Some email clients can add additional padding above or below the cell contents in some scenarios, breaking your design for no obvious reason.

CSS and general font formatting


While some email designers do their very best to avoid CSS altogether and rely on the dreaded <font> tag, the truth is many CSS properties are well supported by most email clients. See this comprehensive list of CSS support across the major clients for a good idea of the good properties and those that should be avoided.

Always move your CSS inline


Behind this one is Gmail. Stripping the CSS from the <head> and <body> of any email, we’re left with no choice but to move all CSS inline. The good news is this is something you can automate completely.  Use this step at the end of your build-out process so you can utilize the many benefits of CSS.

Avoid shorthand for fonts and hex notation


Many email clients reject CSS shorthand for the font property. Never set your font styles like this.
p { font:bold 1em/1.2em georgia,times,serif; }

Instead, declare the properties individually as follows:
p {
font-weight: bold;
font-size: 1em;
line-height: 1.1em;
font-family: times,serif;
}

When declaring the color property in your CSS, some email clients don’t support shorthand hexadecimal colors like color:#f60; instead of color:#ff6000;. The longhand approach is the best for great results.

Paragraphs


Similar to table cell spacing, paragraph spacing can be an issue to consistently result across the board. Seeing many designers revert to using double <br /> or DIVs with inline CSS margins to work around these shortfalls, but recent testing showed that paragraph support is now reliable enough to use in most cases (there was a time when Yahoo! didn’t support the paragraph tag at all).

Best approach is to set the margin inline via CSS for every paragraph in your email is:
p { margin: 0 0 1.6em 0; }

Do this via CSS in the head when building your email, then use Premailer to bring it inline for each paragraph later.

If part of your design is height-sensitive and calls for pixel perfection, then avoid paragraphs altogether and set the text formatting inline in the table cell. You might need to use table nesting or cellpadding / CSS to get the desired look. Example:

<td width="200" style="font-weight:bold; font-size:1em; line-height:1.2em; font-family:georgia,'times',serif;">your height sensitive text</td>

Links


Some email clients will overwrite your link colors with their defaults, and you can avoid this by making these two steps. 1 - Set a default color for each link inline:

<a href="http://somesite.com/" style="color:#ff00ff">this is a link</a>

Next, inside the tag add a redundant span.

<a href="http://somesite.com/" style="color:#ff00ff"><span style="color:#ff00ff">this is a link</span></a>

To some this may be overkill, but if link color is important in your design, a superfluous span is the best way to achieve consistency.

Images in HTML emails


Please remember that images in email  won’t be visible by default for many subscribers. If you start your design with that assumption, and make sure to keep things simple as to not suppress important content with image blocking.

Here are the essentials to remember when using images in HTML email:

Avoid spacer images


The nested tables and spacer images were popular a decade+ ago, image blocking in many email clients has won. Some email services place images with an empty placeholder in the same dimensions, others strip the image complete out. Image blocking is on by default in most emails, this can lead to a bad first impression for many of your subscribers. Stick with fixed cell widths to keep your formatting in place regardless.

Include the dimensions of your image


If you don't set the dimensions for an image,  the email service could invent their own sizes when images are blocked and break your layout. Ensure that any images are correctly sized before adding them to your email. Some email clients will ignore the dimensions specified in code and rely on the true dimensions of your image.

Avoid PNGs


Lotus Notes 6 and 7 won't support 8-bit or 24-bit PNG images, best bet is to stick with the GIF or JPG formating for all images.

Provide default colors for background images


Some Outlook versions have no support for background image. If you intend to use a background image in your design, always provide a background color the email client can default to. Solving both the image blocking and Outlook problem at the same time.

Don’t forget alt text


Providing alt text is important from an image blocking perspective. Even with images hidden by default, many email clients will display the provided alt text.

Don’t use floats


Both Outlook 2007 and earlier versions of Notes offer no support for the float property. Instead, use the align attribute of the img tag to float images in your email.

<img src="image.jpg" align="right">

If you’re seeing strange image behavior in Yahoo! Mail, adding align=“top” to your images can often solve this problem.

Video in email


With no support for JavaScript or the object tag, video in email (if you can call it that) has long been limited to animated gifs. However, some recent research I did into the HTML5 video tag in email showed some promising results.

Turns out HTML5 video does work in many email clients right now, including Apple Mail, Entourage 2008, and the iPhone. The real benefit of this approach is that if the video isn’t supported, you can provide reliable default content such as a clickable image linking to the video in the browser.

The question of whether you should add video to email is another issue altogether. If you lean toward the “yes” side check out the technique with code samples.

What about mobile email?


With the advent of the iPhone, Android, it’s becoming less important to think of mobile as a different email platform altogether.

A few key pointers to keep in mind when coding your emails to get a decent result for your more mobile subscribers.

Keep the width less than 600 pixels


Due to email client preview panes, this rule has been important long before mobile email clients. Truthfully, the iPhone, the Droid 480 pixels and the Blackberry models are around 360 pixels. Sticking to a maximum of 600 pixels wide ensures your design should still be readable when scaled down for each device. This width also gives good results in desktop and web-based preview panes.

Be aware of automatic text resizing


In what is almost always a good feature, email clients using webkit (such as the iPhone, Pre and Android) can automatically adjust font sizes to increase readability. If testing shows this feature is doing more harm than good to your design, you can always disable it with the following CSS rule:

-webkit-text-size-adjust: none;

Don’t forget to test


While standards support in email clients hasn’t made much progress in the last few years, there has been continual change (for better or worse) in some email clients. Web-based providers like Yahoo!, Hotmail and Gmail are notorious for this. On countless occasions I’ve seen a proven design suddenly stop working without explanation.

It’s important to retest your email designs on a regular basis. A quick test every month or so does the trick, especially in the web-based clients. The good news is that after designing and testing a few HTML email campaigns, you will find that order will emerge from the chaos. Many of these pitfalls will become quite predictable and your inbox-friendly designs will take shape with them in mind.

Looking ahead


Designing HTML email can be a pain in the booty for new designers and standardistas to swallow, especially given the fickle and retrospective nature of email clients today. With HTML5 just around the corner we are entering a new, uncertain phase. The aim of groups such as the Email Standards Project is to make much of the above advice as redundant as the long-forgotten <blink> and <marquee> tags, however, only time will tell if this is to become a reality.

Although not the most compliant medium, the results speak for themselves – email is, and will continue to be one of the most successful and targeted marketing channels available to you. As a designer with HTML email design skills in your arsenal, you have the opportunity to not only broaden your service offering, but gain a unique appreciation of how vital standards are.