Building an email is not like building for the web. While web browsers continue to improve their compliance with standards, many email clients have not.
Rest assured, creating HTML for email can be done despite its unique challenges. The key is to focus on three things:
- SIMPLE DESIGN: The more complex your email design, the more likely it will fail on a popular client with poor standards support.
- SIMPLE CODE: Take your coding skills to 1998. That often means using nesting tables, inline CSS, and basic HTML elements.
- TESTING OFTEN: Test your designs regularly as email clients can add or revoke support at any time. An email template that looks good in Hotmail one day may look odd the next.
Tip: Decide exactly which email clients you plan on supporting when building an HTML email
While general research is helpful, the email clients your subscribers use can vary significantly. If you know none of your recipients are using a particular client, save yourself some frustration and ignore it altogether.
Tip: Use a test management service like Litmus.com or emailonacid.com
Knowing which email clients you’re targeting not only makes the building process easier, it can save you a lot of time in the testing phase too. Just remember that pixel perfection in all email clients is a pipe dream.
Design Considerations
Because clients like Gmail and Outlook 2007 have poor support for float, margin, and padding, you’ll need to use tables to build your email framework. Keep in mind that although nested tables are widely supported, consistent treatment of width, margin, and padding within table cells is not.
Follow these tips to get the best results when creating your table structure:
Tip: Set cell width, not table width
Combining widths and padding for your table and CSS will result in varying appearances across different email clients. The most reliable way to maintain consistent width across email clients is to set a width for each cell instead of the table.
<table cellspacing="0" cellpadding="10" border="0"><tr><td width="80"></td><td width="280"></td></tr></table>
- Never assume that if you don’t specify a cell width, the email client will figure it out. It won’t. Also, avoid using percentage-based widths. Clients like Outlook 2007 don’t respect them, especially for nested tables. Stick to pixels. If you want to add padding to each cell, use either the cell padding attribute of the table or CSS padding for each cell, but never combine the two.
Table nesting is far more reliable than setting left and right margins or padding for table cells. If you can achieve the same effect by table nesting, you will always get the best result across the buggier email clients.
Many email clients ignore background colors specified in your CSS or the <body> tag. Wrap your entire email with a 100% width table and give that a background color to work around this.
<table cellspacing="0" cellpadding="0" border="0" width="100%"><tr><td bgcolor=”#000000”>Your 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.
Tip: Avoid unnecessary white space in table cells
Where possible, avoid whitespace between your tags. Some email clients can add additional padding above or below the cell contents, breaking your design for no apparent reason.
While some email designers do their best to avoid CSS altogether and rely on the tag, the truth is most email clients well support many CSS properties.
Some web clients strip CSS from the end of emails, so move all CSS inline.
Some email clients reject CSS shorthand for the font property. For example, avoid setting your font styles like this:
p { font:bold 1em/1.2em georgia,times,serif;}
Instead, declare the properties individually like this:
p { font-weight: bold; font-size: 1em; line-height: 1.2em; font-family: georgia,times,serif;}
Support for @font-face across major email clients is abysmal. It’s much better to use web-safe fonts in email. When declaring the color property in your CSS, some email clients don’t support shorthand hexadecimal colors like color:#f60; instead of color:#ff6600. Stick to the longhand approach for the best results.
Just like table cell spacing, paragraph spacing can be tricky to get a consistent result across the board. The best approach is to set the margin inline via CSS for every paragraph in your email, like so:
<p style="margin: 0 1 1.6em 0;">
If part of your design is height-sensitive and calls for pixel perfection, I recommend avoiding paragraphs altogether and setting the text formatting inline in the table cell. You might need to use table nesting or cell padding / CSS to get the desired result. Here’s an 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>
Tip: Customize the color of your links
Some email clients will overwrite your link colors with their defaults, and you can avoid this by taking two steps. First, set a default color for each link inline like so:
<a href="http://somesite.com/" style="color:#ff00ff">this is a link</a>
Next, add a redundant span inside the <a> tag.
<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 to your design, then a superfluous span is the best way to achieve consistency.
Images in HTML emails
The most important thing to remember about images in email is that they won’t be visible by default for many recipients. If you start your design with that assumption, it forces you to keep things simple and ensure no important content is suppressed by image blocking. With this in mind, here are the essentials to remember when using images in HTML email:
Tip: Avoid spacer images
While the combination of spacer images and nested tables were popular on the web ten years ago, image blocking in many email clients has ruled it out as a reliable technique today. Most clients replace images with an empty placeholder in the same dimensions. Others strip the image altogether. Given image blocking is on by default in most email clients, this can lead to a poor first impression for many of your subscribers. Stick to fixed cell widths to keep your formatting in place with or without images.
Tip: Always include the dimensions of your image
Email clients may enforce their own size standards when images are blocked and break your layout if you forget to set the dimensions for each image. Also, ensure that any images are correctly sized before adding them to your email. Some email clients will ignore the dimensions specified in the code and rely on the true dimensions of your image.
Outlook 2007 has no support for background images (aside from this hack to get full page background images working). If you want to use a background image in your design, always provide a background color the email client can fall back on. This solves both the image blocking and Outlook 2007 problem simultaneously.
Lack of standards support means email clients have long destroyed the chances of a semantic and accessible HTML email. Even still, providing alt text is important from an image blocking perspective. Even with images suppressed by default, many email clients will display the provided alt text instead. Remember that some email clients like Outlook 2007, Hotmail, and Apple Mail don’t support alt text when images are blocked.
Tip: Use the display hack for Hotmail
For some inexplicable reason, Windows Live Hotmail adds a few pixels of additional padding below images. A workaround is to set the display property like so.
img {display:block;}
This removes the padding in Hotmail and still gives you the predictable result in other email clients.
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">
What about mobile email?
The mobile email landscape was a huge mess until recently. With the advent of the iPhone, Android, and big improvements from Palm and RIM, it’s becoming less important to consider mobile as a different email platform altogether. That said, there are 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.
Because of email client preview panes, this rule was important long before mobile email clients came of age. In truth, the iPhone and Pre have a viewport of 320 pixels, the Droid 480 pixels, and the Blackberry models hover 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.
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;
Tip: Test emails regularly
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. For this reason alone it’s important to retest your email designs on a regular basis.