How to Code HTML Email Newsletters
Step 2: Add CSS Styles
Did I say CSS support was poor in mail clients? Well, it is. But you can (and should) still utilize CSS for the styles in your email once your nested table layout is in place. There are just a few things to watch out for. Here are the steps that I use.
First, use inline styles to store all of your style information, as shown here:
<p style="color: red;">
a, and so on.
Do not use the CSS
style declaration in the HTML
head tag, as you might when authoring web pages. Instead, place your
style declaration right below the
body tag — Google Mail, in particular, looks for any style in the email and (helpfully) deletes it. Also, don’t bother using the
link element to reference an external style sheet: Google Mail, Hotmail, and other email software will ignore, modify, or delete these external references to a style sheet.
For your container table — the one that houses the header, content, and footer tables — set the table width to 98%. It turns out that Yahoo! mail needs that 1% cushion on either side in order to display the email properly. If side gutters are critical to your email’s design, set the width to 95% or even 90% to avoid potential problems. Of course, the tables inside the container table should be set to 100%.
Put general font style information in the table
td, closest to the content. Yes, this can result in repetitive style declarations within multiple
td cells. Put font style definitions into heading (e.g.
a tags only when necessary.
divs sparingly to float small boxes of content and links to the right or left inside a table’s
td cell. Google Mail, for one, seems to ignore the CSS float declaration (yet Yahoo! and Hotmail cope with it just fine). Sometimes it’s better to code a more complex table layout than to rely on the float declaration. Or, since it’s all too easy to clutter up an email, ask your designer to put the floated content in the narrow side column instead. Flaky support for floats is one issue that may cause an email design to be reworked.
divs appear to be barely useful,
spans appear to work almost every time, because they’re inline elements. In some cases,
spans can be used for more than just coloring or sizing text: they can be used to position text above or below content.
Note that some email delivery services will unpack style definitions to make them more explicit and, therefore, more readable by all email software. For example, the CSS shorthand
style="margin: 10px 5px 10px 0;" may be expanded into the long style declaration shown earlier. Test each email and look to see what happens to the email code. Start with CSS shorthand because, in the worst case, it appears to work well with all email software.
If you’ve downloaded and studied the email templates from Campaign Monitor and MailChimp, you’ll see that they treat the container table as if it were the
body tag. The Campaign Monitor team refer to this table as the “BodyImposter,” which is a great way to think about the frame or wrapper table. From a CSS perspective, the container table does what the
body element would do if services like Google Mail didn’t disable or ignore the
Step 3: Adopt Best Practices
Knowing that you’ve created valid HTML email using the guidelines I’ve suggested is only part of the solution — there are several best practices that you should follow to ensure that your email is well received.
The next step is to test your HTML email in a variety of email clients. Often this will identify problems that require workarounds.
The first test tools to use are the Firefox and Internet Explorer web browsers. If the email displays well or perfectly in both browsers, there’s a good chance that testing the email in Outlook, Yahoo!, Google Mail, and other services will reveal only minor problems. I’d also recommend testing your email in Internet Explorer 6 — this should give you a good indication of how your email will render in Outlook 2003 (refer to the list of resources at the end of this article for information on running Internet Explorer 6).
Once the email appears fine in those two web browsers, use an email delivery service to send the email to a range of test email accounts. Ideally, this should include accounts with the Yahoo!, Hotmail, and Google Mail services.
The test accounts you use should, of course, be determined by the domain names in the mailing list of people who will receive the email. For example, if there are no AOL subscribers on this list, it’s probably a waste of time and money to set up, and test with, an AOL email account.
Here are the most common code tweaks that I’ve found necessary during this test phase:
- Sometimes, a switch from percentage widths to fixed widths is needed. While this is not ideal — because readers can and do resize their email windows while reading — sometimes, using a fixed width is the only way to have a layout to display properly in multiple email clients.
- If there’s a spacing issue with the columns in the email design, first tweak the
cellspacingattributes of the HTML tables. If that doesn’t work, apply CSS
paddingattributes. HTML spacing works better with older email software.
- Image displacement can occur when a
tdcell is closed right below an
imgtag. This is an ancient HTML problem. Putting the
</td>tag right after (on the same line as) the
imgtag eliminates the annoying and mystifying 1-pixel gap.
In addition, the following best practices are recommended:
- If an image is sliced up and spread across several HTML table cells, test the email using many test accounts. Sometimes, it might look great in Outlook but be shifted by one or more pixels in Hotmail and other services. Also consider making the image a background image on a new HTML table that encases all of the table rows and columns that would display parts of your background image; this often achieves the same effect as slicing an image up, but uses less code and can provide better results (see below). Note that Outlook 2007 does not display background images; be sure to test your email code with your target email software.
- For background images, use the table’s
backgroundattribute instead of using CSS. This works more consistently across email software than other potential solutions.
- Store the email images on a web server — preferably in a folder that’s separate from your web site’s images (for example, in a folder called
/images/email), and don’t delete them. Some people open emails weeks or months later, the same way people use bookmarks to return to web sites.
- Be sure all your images use the
widthattributes. Setting values for these attributes improves results in Google Mail, as well as maintaining your layout when a reader has their images turned off. Note, however, that Outlook 2007 does not recognize the
- Use the
target="_blank"attribute for the a tags, so that people who read with webmail services don’t have the requested page appear within their webmail interface.
- While a 1×1-pixel image can be used to force spacing to create a precise email layout, spammers often use 1×1-pixel images to determine if their email has been opened. As such, using this practice will increase the likelihood that your email is classified as spam.
- Similarly, avoid using a large image “above the fold” in the email. This is another classic spammer practice and may cause your email to be interpreted as spam.
It’s important to make sure your HTML email displays acceptably with images turned off. Thunderbird, Outlook and many other email applications set the display of images to “off” by default. For example, if you use a background image to provide a background color with white font color over it, make sure the default background color for that part of the HTML table is dark, not white.
When I’m testing how an email displays with images off, I usually use my text editor to replace each image’s
src attribute with a unique combination of characters such as “xsrcx”, and then revert it back again after the test.
As part of testing an email, also include a test for potential “spamminess”. SpamCheck is a useful service that highlights issues that might cause an email to trigger spam filters. While it comes bundled as a tool called Site Build It, that is available for purchase, the online version of SpamCheck is a free service, and no purchase is necessary to make use of it.
Once the HTML email has been tweaked so that it displays well in your test email accounts, the next step is to go through a checklist. For example, verify the following:
- Does the From address display properly (as a name, not a bare email address)?
- Is the subject line correct?
- Is the contact information correct and visually obvious?
- Does the top of the email display the text, “You received this email because … Unsubscribe instructions are at the bottom of this email.”?
- Does your email contain text asking readers to add your From address to their email address book?
- Does the top of your email include a link to the web version of the message?
If it’s important for you to know absolutely everything that could go wrong with the way your HTML email is rendered, try a service like Browsercam.com. For a small hourly fee, you can post the email as a web page on a server, then point Browsercam at the page. Browsercam will take snapshots that show how the email appears on a wide range of browsers and operating systems. While the snapshots don’t show how email software will display an email, many email clients use web browser components to display HTML email, so Browsercam is a good way to increase the chances that you will spot any rendering issues.
And if you enjoyed reading this post, you’ll love Learnable; the place to learn fresh skills and techniques from the masters. Members get instant access to all of SitePoint’s ebooks and interactive online courses, like Create Stunning HTML Email That Just Works!.
Comments on this article are closed. Have a question about HTML email? Why not ask it on our forums?