From www.sitepoint.com by Tim Slavin. November 5th 2004

HTML email newsletters are a win-win for publishers and readers. Publishers can track rates for email opens, pass-throughs, and click-throughs to measure reader interest. Readers get information laid out like Web pages which is (in theory) much easier to scan and navigate than a top-down plain text email.

For programmers, however, coding HTML email newsletters can be a mixed bag of joy, misery, and pain.

The biggest misery is that some email software programs slice your precious code into their overly elaborate and inscrutable HTML formats and CSS styles.

By far the greatest challenge is that people use many different software tools to read their email, from Eudora to Outlook, AOL to Thunderbird, LotusNotes to Web-based services such as Yahoo! and Hotmail. Worse, Webmail services like Hotmail use CSS stylesheets that overwrite the styles you use in your HTML email newsletter, messing up your design.

I have found very little information that describes the differences between email clients, for example, how well they support HTML, XHTML, and CSS. I find even less information that explains how to code with HTML and CSS an email newsletter that will display intact in most -- if not all -- email clients.

Years ago, I had to create an email newsletter in HTML format and ran smack into the problem of too little email reader documentation and no coding guidelines. I found no information about what HTML to include and exclude (and for what reasons!) so that the HTML would be visible in most email software.

This article describes what has worked for me. Your mileage may vary, so I welcome feedback based on your experience. I'll provide you the big picture followed by instructions and some final subtleties to consider.

The Big Picture

Firstly, I would encourage you to code HTML email newsletters by hand. This is partly my own preference to have total control over my code. Additionally, I've had bad experiences, and considerable rework result from the use of WYSIWYG editors. In fact, email newsletters happen to be an easy and fun hand coding project, as you will see.

Secondly, HTML email newsletter code needs to be self-contained. It should include embedded stylesheet information, use HTML tables to implement the design layout, and the design should be "fluid" (expand/contract automatically to fit the width of any email software) rather than "fixed" in width. A fluid design ensures your email layout will remain intact regardless of whether your reader uses a PDA or computer with their email window open fully, or only partially. (There is a counter-argument to fluid HTML newsletter design; see the Subtleties section below for details.)

I code HTML email newsletters as a single Web page with the basic HTML, HEAD, TITLE, and BODY tags. I embed my CSS styles between the close TITLE and close HEAD tags, as I do with Website pages. I find that Webmail clients (HotMail, Gmail, etc.) that remove or rewrite these basic tags will still generally leave my CSS styles valid and usable.

The typical HTML email newsletter layout includes a header across the top, 2-3 columns under the header, and a footer beneath the columns. This arrangement can be coded in HTML as three HTML tables stacked one on top of the other (a header table, 1-3 column content area table, a footer table), or a single HTML table with rows and columns (and colspans, as needed). For me, stacked HTML tables work best for HTML email newsletters.

Finally, I encourage you to use the simplest layout possible. Yes, you can slice up a big image and have it display across HTML table cells. But it is less complex a task to code a 2-column layout and, therefore, you runs a smaller risk that a reader will see your email as broken. Some days, you have a choice. Some days, you do not.

Also be aware that usability tests show that simpler, top-to-bottom layouts work best for newsletters. People are used to scanning email from the top to the bottom. So, use columns, side boxes or other visual distractions only to draw readers' attention to important information, and to facilitate scanning.

Step 1. Use HTML Tables for Layout

Let's start with the basic HTML table layout code that I use to begin my email projects:

<table id="frame" border="0" cellspacing="0" cellpadding="0">
<tr>
<td>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
    <TD id="header" valign="top" align="right">
    <p>Header Table image/links/content goes here. </p>
    </div></td>
</tr>
</table>
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
   <TD id="leftcol" valign="top" align="left">
   <h1>Head 1</h1>
   <p>Left column text.</p>
   </div></td>
   <TD id="content" valign="top" align="left">
   <h1>Head 1</h1>
   <p>Content area text/images/links go here.</p>
   </div></td>
   <TD id="leftcol" valign="top" align="left">
   <h1>Head 1</h1>
   <p>Right column text.</p>
   </div></td>
</tr>
</table>
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
   <TD id="footer" align="center" valign="middle">
   <p>Footer text/images/links go here. </p>
   </div></td>
</tr>
</table>
</td> |
</tr>
</table>

If you study this code, you will notice a few items that require explanation.

We use a table, tagged with id="frame", that encases the 3 other tables. We reference this parent table in the same way you might reference the HTML body tag in CSS. Without this 'frame' table, Web-based email tools like Yahoo! will use their body tags to calculate the CSS rules in your email newsletter.

We tag the HTML TD cells with a style, then close that style with a </div> tag right before we close the TD cell. Why? A while back, I got an email from a reader who has a Mac, but could not see my Web page ...until I stumbled across this hack. She had N5 or N6. This is a move on my part to avoid the same problem with email readers using those browsers. Of course, this is very much a hack and is definitely NOT standards-compliant. But if you do have significant numbers of Mac users with Netscape mail clients, you now have an option up your sleeve.

We tag the TD cells with layout styles to define, for example, widths and fonts. There is a school of thought that says this is wrong -- see the Subtleties section below. Styling TDs this way has worked for me so far, however.

All the tables have the border attribute set to '0' by default. Commonly, I'll set the property to border="1" to help with the debugging process. As you'll see below, we can also do this with CSS to debug CSS problems.

We also set the table 'cellpadding' and 'cellspacing' attributes to 0. Should you use these for spacing or CSS styles? I use CSS because it is more precise, but these table properties work fine, too. (See the Subtleties section below for more detail.)

Using HTML tables, instead of CSS, for layout may seem retro but it is critical if you want your email code to be readable by older email clients. Notice, however, that I do not advocate using HTML font tags! (See the Subtleties section below for the argument that FONT tags work best.) Mixed HTML and CSS will at least make it easier to migrate your code if and when all email readers become standards-compliant -- probably the day you see pigs fly outside your window.

Step 2. Use CSS Styles

If you studied the HTML table code in Step 1, you'll have noticed that we tagged different parts of the HTML table layout with CSS styles. But, before we discuss how CSS and HTML table code work together in an email newsletter, here's the embedded CSS stylesheet information for the table code in Step 1. We place this code between the close TITLE and close HEAD tags.

<style type="text/css">
<!--

body {  
background: #ffffff;
color: #000000;
margin: 20px 20px 0 20px;
padding-left: 0px;
font-family: normal 10px/14px verdana,trebuchet,sans-serif;
text-align: left;
}

#frame {
background: #ffffff;
width: 98%;
border: 0px solid #000000;
}

#header {
background: #000000;
color: #ffffff;
text-align: left;
padding-left: 0px;
width: 100%;
}

#leftcol {
width: 20%;
text-align: left;
padding: 5px 5px 0 20px;
vertical-align: top;
}

#content {
width: 60%;
text-align: left;
vertical-align: top;
margin-left: 20px;
padding: 5px 0 20px 20px;
}

#footer {
background: #336633;
color: #ffffff;
padding: 3px 0;
}

a, a:visited {
background: transparent;
color: #aa0000;
font: bold 12px/14px verdana, trebuchet, sans-serif;
text-decoration: none;
}

a:hover {  
text-decoration: underline;  
}

p, td, th, ul, ol, ul, li, dl, dt, dd {
font: normal normal normal 10pt/15pt verdana, trebuchet, sans-serif;
}

#header p, #leftcol p, #content p, #footer p {
font-family: 10px/14px verdana, trebuchet, sans-serif;  
text-align: left;
}

#header H1, #leftcol H1, #content H1, #footer H1 {
font-family: bold 14px/18px verdana,trebuchet,sans-serif;
background: transparent;
color: #669966;
padding: 5px 0 0 0;
}

-->
</style>

If you study these CSS styles, you'll notice a few things:

I use the "trouble" (trouble: Top Right Bottom Left) shorthand format to set margins and padding. This reduces the amount of code within my HTML file which, in turn, helps reduce the spam rating of my email. Of course, it also reduces my email file size.

I put common styles like P and H1 in the context of the TD cell they inhabit (header, leftcol, content, and footer). As with using the 'frame' ID to replace the body tag info, referencing these tags through their parent ensures that styles used by Webmail will not override the styles you use in your email. UL, LI, STRONG also are good candidates for this treatment.

I use 'leftcol' to style the left and right columns in my layout design. This reduces code, which, as noted above, helps reduce the spam rating of any email I send.

In the CSS rule for 'frame', I have a border style with 0px set as the width. When problems arise, I set the width to 1px and move this style from rule to rule to debug problems. Seeing the outline of a style often helps identify a problem.

In the CSS rule for 'frame', I set the frame at 98% width to leave space on either side. Through trial and error I discovered that many Webmail clients, such as Yahoo!, need a value less than 100% to ensure an email newsletter displays properly.

The p, td, th, ul, ol, ul, li, dl, dt, dd compound style is intended solely for very old browsers. I use it when I code Websites and find it works with email. I also place this style near my P and A styles so that changing the font size can be maintained easily across styles that I use to control font size.

I've assumed that you know CSS (and HTML) in depth and do not need an explanation of CSS and CSS styles. The references I use are SitePoint's HTML Utopia: Designing Without Tables Using CSS, Jeffrey Zeldman's Desigining with Web Standards, and Eric Meyer's Eric Meyer on CSS. There also are a number of excellent online resources about CSS, in addition to SitePoint.com's CSS section. For example, SimpleBits.com has a terrific ongoing feature called SimpleQuiz that discusses and debates the virtues of different ways to code CSS to solve problems.

Step 3. Test Your Code

My experience is that the best way to test code is to code in a methodical way. First, I build my table in HTML, use the table border="1" attribute to confirm the layout displays properly, then add the styles for each table data (TD) cell. I confirm that the styles work one by one, then add character styles (e.g. P, A, H1) within each part of the layout (e.g. the header, content areas, and footer). My final step is to make sure that the character styles are protected from Webmail rewriting by being defined as children of individual TD layout styles. For example, instead of using a P style, I use a #content P style, a #header P style, and so on.

I find that, if I debug the layout code before I add the character styles I find it much easier to work backwards when code fails. The alternative is to code a little layout, then a little character, then a little more layout. My experience is that a mixed coding process is the surest road to confusion.

Once my code works in my Firefox and IE 6 web browsers, I use an email service provider to send my HTML email newsletter to test accounts at Yahoo!, Optimum Online (my internet ISP), another Webmail account, and my business email account that displays in Outlook. Look at your list of email addresses to determine where to set up test email accounts. If many of your readers use AOL, I recommend you sign up for an AOL account.

I also have an account with Browsercam, an online service that shows how my code renders in many different combinations of Web browsers and operating systems. I pay US$10 an hour for a number of URLs. I post my email newsletter as a Web page on one of my Websites, then feed that URL into Browsercam.

One note about Browsercam, however, is that I find it shows a lot of warts. It's not clear to me that a design slightly off in Linux using Konquerer is a problem if my list does not appear to have people using that combination. Browsercam is best suited to my skittish clients who want proof positive that what I code works across platforms.

Often, I post a notice in my HTML newsletters to ask for feedback if the newsletter does not display properly for a reader. It's not a perfect way to test, but once or twice people have pointed out issues that were unknown to me.

Finally, develop a short checklist to run through before you send each email. Check that the From address displays properly, the subject line is correct, your contact information is correct and obvious, your unsubscribe instructions are simple and obvious, and so on. Ask someone else to use your checklist to inspect your work.

My weakness is that I miss one obscure detail on every project. My siblings still tease me for once jumping on the right train, at the right time, at the right station, going in the wrong direction: to San Francisco instead of San Jose! A thorough checklist helps me find that overlooked detail before my clients or readers find them.

The bottom line is that your test process must yield flawless code. If you've ever done book design and layout work, you'll probably have internalized the proper level of compulsiveness. Otherwise, check every last detail before you send your email.

Subtleties

I have described the basics of coding mixed HTML and CSS so that your newsletter will display across the majority of (perhaps all) email clients. There are a few subtleties, however, that you should be aware of so that you can handle them as you wish.

• I've read that older email clients cannot parse widths expressed in percentages in HTML table code. While I have never encountered this problem, it does present a good argument for using a fixed width layout for your HTML tables and table cells. The advantage of my email scaling to any width email client, however, makes a fluid layout (using percentages) more valuable than fixed width. If you use fixed width, your email design should be no wider than 600 or 620 pixels.
• In a similar vein, I have read that avoiding styles for <BODY>, <P>, <TD>, <LI>, and <UL> is best. Certainly that could be true for complex layouts. But I have never had a problem with Webmail clients rewriting these common tags if I tuck the styles within a parent ID, for example, #header P {…} instead of P{…}. If you disagree, you should rely mostly on HTML and only a little on CSS.
• At least one resource says that everything I've described above will not work. For example, they encourage use of the FONT tag instead of P tags. What I have laid out above works for me across every email client I've tested ...but you may disagree.
• Avoid JavaScript. Period. Most email software today disables JavaScript, and you'll find that newsletters with JavaScript are much more likely to be treated as spam.
• You can use 1x1 spacer gifs to force widths in your table data cells. However, spammers often use 1x1 pixels so (in theory) you may flag your email as spam.
• It is possible to slice up a complex image across HTML table cells. However, you should use a service like Browsercam to confirm that your design is not shifted by 1 pixel or more when displayed by different Web browsers. There may be not displacement within Outlook, for example, yet the email may be broken in Hotmail.
• While use of HTML tables to lay out your design eliminates most of the width issues you'll see with IE browsers and Web pages, you may encounter width issues where the width displays fine in Firefox, but poorly in IE and, therefore, Outlook. If you can use HTML table code to solve the problem (for example, the 'cellspacing' or 'valign' attributes), use that before you try a CSS workaround. Named Anchors (i.e. a name="nav") have always worked fine for me but I have received emails from others who have encountered problems.
• I use the target="_blank" attribute for my A tags (links) so that people reading a newsletter with Webmail keep their email inbox intact. Using target="_blank" will open a new browser window. Otherwise, clicking on a link will replace their Webmail inbox with the requested content, and they'll have to use the browse button to go back.
• My preference is to not embed images in my HTML code. For one thing, it increases the file size of my HTML email newsletter. Some email software like MojoMail will embed images in your email. However, the reporting capability of MojoMail is not as robust as most email service providers. There are tradeoffs.
• If you want to use a background image, use the HTML table background= attribute rather than the CSS equivalent. It works more consistently across email clients.
• Image displacement can occur when you close a table data cell after an image, or when you close a style after an image. Put the </td> tag next to the image code. And remember: you can use <br /> instead of the <p> style.
• Avoid placing big image files above the fold. This is another classic sign of spam.
• Windows XP Service Pack 2 automatically (and helpfully!) strips out images from some HTML email newsletters. The reason? Spammers often use 1x1 image tags to tell if an email account is still 'live'; when you open such an email, a URL is called that notifies the spammer that your email works. Legit marketers use similar techniques to track open rates, click-throughs, and other important metrics. Microsoft, in its infinite wisdom, blocks all images. The only solution is to have your readers add your newsletter email address to their address book.
• Use of templates for your email newsletters is a good idea. However, be aware that rigid use of the same template can make your email newsletter vulnerable to phishing scams where scammers replicate your email, send it to your list, and use the familiarity of your email template and brand to steal personal data.
• Finally, notice I have not specified which version of the HTML and CSS standards to use. Use the simplest and lowest common denominator. Don't use CSS to lay out your design, for example. And while the use of HTML entities (such as &copy;, &nbsp; and &reg;) makes your code XHTML compliant, are HTML entities supported in all email clients? Be aware that you have a choice. Use basic HTML wherever possible and use CSS to streamline common formatting like fonts, image placement, and so on.

Many people who receive email newsletters prefer HTML over text for any number of reasons. From the programmer's point of view, however, the task of coding an HTML email newsletter can appear both simple and horribly complex. I hope I've described many of the issues and coding strategies that will work across email clients.

The key point is: if you have to choose between a simple coding solution and a more complex solution, simplicity works better every time for HTML email.