In some ways, coding HTML email has become easier — several email software providers, such as Google Mail, have improved their support for CSS. However, at the same time, Outlook 2007 has taken HTML email backwards: last year Microsoft substituted the original HTML rendering engine used by Outlook for an engine that is inferior in terms of CSS support.
Other advances in HTML email in the last couple of years include the formation of the Email Standards Project, which aims to test the compliance of email software to HTML and CSS standards and to lobby for improvements; the emergence of services for testing how HTML email renders in various desktop and web-based email applications; and the availability of HTML email templates that you can either use “as is” or customize to your preferences. We’ll look at some of these services and templates in this article.
Despite these advances, coding HTML email can be a mix of misery and pain for programmers. This article will bring you up to date on how to code HTML email so that it will display well in most email software.
HTML Email Fundamentals
The biggest pain when coding HTML email is that so many different software tools are available for reading email, from desktop software such as Eudora, Outlook, AOL, Thunderbird, and Lotus Notes, to web-based email services such as Yahoo!, Hotmail, and Google Mail. If you thought it was difficult to ensure the cross-browser compatibility of your web sites, be aware that this is a whole new ball game — each of these email software tools can display the same email in vastly different ways. And even when these tools do display an HTML email properly, accounting for variances in, for example, and the widths at which readers size their windows when reading emails makes things even trickier.
Whether you choose to code your HTML email by hand (my personal preference) or to use an existing template, there are two fundamental concepts to keep in mind when creating HTML email:
Use HTML tables to control the design layout and some presentation. You may be used to using pure CSS layouts for your web pages, but that approach just won’t hold up in an email environment. Use inline CSS to control other presentation elements within your email, such as background colors and fonts.
The quickest and easiest way to see how HTML tables and inline CSS interact within an HTML email is to download some templates from Campaign Monitor and Mail Chimp. When you open up one of these templates, you’ll notice a few things that we’ll discuss in more detail later:
CSS style declarations appear below the body tag, not between the head tags. No CSS shorthand is used: instead of using the abbreviated style rule font: 12px/16px Arial, Helvetica, you should instead break this shorthand into its individual properties: font-family, font-size, and line-height. spans and divs are used sparingly to achieve specific effects, while HTML tables do the bulk of the layout work. CSS style declarations are very basic, and do not make use of any CSS.
Step 1: Use HTML Tables for Layout
That’s right: tables are back, big time! Web standards may have become the norm for coding pages for display in web browsers, but this isn’t the Web, baby. Mail clients are many years behind the eight-ball in terms of CSS support, which means that we must resort to using tables for layout if we really want our newsletters to display consistently for every reader. So put your standards-compliant best practices and lean markup skills aside: we’re about to get muddy!
The first step in creating an HTML email is to decide what kind of layout you want to use. For newsletters, single column and two-column layouts work best, because they control the natural chaos that results when a large amount of content is pushed into such a small space as an email.
A single-column layout typically consists of:
a header, containing a logo and some (or all) of the navigation links from the parent web site to reinforce the branding and provide familiarity for site visitors intra-email links to stories that appear further down in the email a footer at the bottom of the email, which often contains links that are identical to the top navigation, as well as instructions for unsubscribing
Two-column emails also use a header and footer. Like a two-column web page, they typically use a narrow, side column to house features and links to more information, while the wider column holds the body content of the email.
Promotional emails follow similar rules but contain much less in the way of content and links. They often include one or two messages, and sometimes make use of one big image with small explanatory text and some links below the image.
All of these email layout possibilities can be created easily, using HTML tables to divide up the space into rows and columns. In fact, using HTML tables is the only way to achieve a layout that will render consistently across different mail clients.
No matter how your email is designed, it’s important to remember that the most important content should appear at or near the top of the email, so it is visible immediately when a reader opens your email. The top left of an email message is often the first place people look when they open an email.
The following is the approach that you should use to create HTML emails:
For a two-column layout, create one table each for the header, the two center content columns, and the footer — that’s three tables in all. Wrap these tables into another container table. Use the same approach for single-column layouts, but give the content table one column. This approach is especially suitable if the design of your email contains images that are broken up over multiple table cells. Otherwise, a single table with td rows for its header (with colspan=”2″ if the design uses two columns), content, and footer should display fine in all but Lotus Notes email software. Use the attributes within the table and td tags to control the table’s display. For example, setting border=”0″, valign=”top”, align=”left” (or center, if that suits the design), cellpadding=”0″, cellspacing=”0″, and so on. This primarily helps older email clients to display the email in a (barely) acceptable way. Even if the design of your email doesn’t include a border around your table, you might find it helpful during development to set border=”1″ to help with the debugging of any problems that arise with the internal alignment of tr and td tags. Change it back to border=”0″ for testing and production.
While this approach might offend purists who prefer to code using the latest standards, it is the only approach that’s viable at this point. But the fact that we’re using tables for layout doesn’t mean we need to resort to old-school methods entirely. For example, no matter how poorly Lotus Notes displays HTML email, you should never have to resort to using the font tag. And while Outlook 2007’s HTML rendering engine is less than perfect, it does display basic HTML tables just fine.
There are some caveats, though; let’s take a look at styling our text next.
Step 2: Add CSS Styles
The fact is that CSS support is poor in mail clients. But you 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 you should follow:
First, use inline styles to store all of your style information, as shown here:
This includes table, td, p, 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 e-mail’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. h1, h2), p, or a tags only when necessary.
Use 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.
While 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 html body tag. The Campaign Monitor team refers 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 html body element would do if services like Google Mail didn’t disable or ignore the body tag.
Step 3: Adopt Best Practices
Knowing that you’ve created valid HTML email using the guidelines we’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. We’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. 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 codes that we’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 cellpadding and cellspacing attributes of the HTML tables. If that doesn’t work, apply CSS margin and padding attributes. HTML spacing works better with older email software. Image displacement can occur when a td cell is closed right below an img tag. This is an ancient HTML problem. Putting the