How To Code HTML Email Newsletters (All New Version)

by Tim Slavin

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 are (in theory) much easier to scan and navigate than 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 slices up your precious code into their overly elaborate and inscrutable HTML formats and CSS styles.

The biggest pain is that people use many different software tools to read their email, from Eudora to Outlook to AOL to Thunderbird to LotusNotes to web-based services such as Yahoo! and Hotmail. Worse, webmail services like Hotmail use CSS stylesheets that overwrite styles you use in your HTML email newsletter, messing up your design.

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

Years ago, I had to create an email newsletter in HTML format and ran smack into this 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 my experiences and what has worked for me. Your mileage may vary so I welcome your feedback based on your experience. I'll provide you the big picture followed by instructions and some final subtleties to consider.

First, I encourage you to code HTML email newsletters by hand. Partly this is my preference to have total control over my code. And partly I have had bad experiences and rework result from using WYSIWYG editors. Email newsletters happen to be an easy and fun hand coding project, as you will see.

Second, 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 to automatically 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 full or 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 CSS styles between the close TITLE and close HEAD tags, as I do with website pages. I find that webmail that removes or rewrites these basic tags still leaves my CSS styles valid and usable.

HTML email newsletters typically have a layout design that includes a header across the top, 2-3 columns under the header, and a footer under 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 works 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 two-column layout and therefore less risky that a reader will see your email as broken. Some days you have a choice. Some days you do not. So it goes.

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

For Steps 1 and 2, you will need to at least print out this basic html email code sample or open it in a new web browser window and refer to it as you read along.

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

• I use a table, tagged with id="frame", that encases the other three tables. I use this table to replace what the HTML body tag does. Without a frame table, web-based email like Yahoo! will use their body tag information in your email newsletter. Your email could be set against a blue background instead of the white you intended.


• I tag the HTML TD cells with a style then close that style with a <./div> tag right before I close the TD cell. Why? Awhile back, I got an email from a reader who has a Mac who could not see my web page until I stumbled on this hack. She had N5 or N6. It's definitely CYA on my part to avoid this problem with any email readers based on those browsers (probably a small number but still…).


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


• All my tables have the border="0" property set. This is to help me debug any layout problems that happen. I set the property to border="1" to find problems. As you'll see below, I also do this with CSS to debug CSS problems.


• I set the table cellpadding and cellspacing values 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.)

Step 2. Use CSS Styles

If you studied the HTML table code in Step 1, you noticed that I tag different parts of the HTML table layout with CSS styles. Before I discuss how CSS and HTML table code work together in an email newsletter, however, here is the embedded CSS stylesheet information for the table code in Step 1. I place this code between the close TITLE and close HEAD tags.

If you study my CSS styles in my basic html email code sample, you'll notice a few things:

• I use the "trouble" shorthand format (top, right, bottom, left) for margin and padding. This reduces the amount of code within my HTML file which, in turn, helps reduce the spam rating of my email. And it reduces my email file size.


• I put common styles like P and H1 in the context of the TD cell styles (header, leftcol, content, and footer). As with using the Frame style to replace the body tag info, putting these tags within their layout styles ensures that styles used by webmail will not overwrite 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 frame style, I have a border style with 0px as the width. When a problem arises, I set the width to 1px and move this style around to other styles to debug problems. Seeing the outline of a style often helps identify a problem.


• In the frame style, I set the frame at 98% width to leave space on either side. I found out Yahoo!, for example, needs this value to ensure an email newsletter displays properly from side to side.


• 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.

My experience is that the best way to test my code is to code in a methodical way. So I first 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, confirm the styles work one by one, and 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 my 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.

When I code this way, coding the layout then the character styles within my layout, I find it very easy to walk 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 hell and 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, you should get an AOL account.

I also have an account with Browsercam, an online service that shows how my code looks in many different combinations of web browsers and operating system. I pay $10 USD an hour for some 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 works best for my skittish clients who want proof positive that what I code works across platforms.

In my email newsletters, I sometimes post a notice asking for feedback if the HTML 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 unknown to me.

Finally, develop a checklist to run through before sending email. Check 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. Shanghai someone to use your checklist to inspect your work.

My weakness is that I miss one detail on every project. My six siblings still harass me for once having the right train, the right time, the right station, the wrong direction, San Francisco instead of San Jose. A thorough checklist helps me find that overlooked detail before my clients or readers find them.

Bottomline, your test process must yield flawless code. If you have done book design and layout work, as I have, you have internalized the proper compulsiveness. Otherwise, check every last minute detail before you send your email.

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

• I have read that older email clients cannot parse widths expressed in percentages in HTML table code. While I have never encountered this problem, it is a good argument to use 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 layout style, 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 everything I have described above will not work (see the CSS-Discuss URL below). For example, they encourage use of the FONT tag instead of P tags. What I have laid out above works fine for me across every email client tested but you may disagree.


• Avoid javascript. Period. Most email software today disables javascript. You will find that newsletters with javascript are 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 in different web browsers. There may be no displacement within Outlook, for example, yet your email appears broken in Hotmail.


• While use of HTML tables to layout 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, with the cellspacing or valign attributes, use that approach before you use a CSS workaround.


• Intrapage jumps work fine for me but I have gotten at least one email asking if I knew workarounds.


• 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 content requested and they'll have to use the browse button to go back. Note that a rare bug happens with Mac OS X mail application (ver 10.2.5) in conjunction with the Safari browser causes links in an HTML email message to fail when they are set to open in a new window. The person who reported this to me said he had 1 instance on his list of 2300 people. I would still use target=_blank but it is your call.


• 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 DadaMail will embed images in your email. However, the reporting capability of MojoMail is not as robust as most email service providers. These are tradeoffs that might not matter to you. (In theory, you could use DadaMail to send yourself your email with images embedded then email it through an email service provider. I have not tried that, however.)


• If you want to use a background image, use the HTML table background= attribute instead of CSS. It works more consistently across email clients.


• Image displacement can occur when you close a table data cell after an image and when you close a style after an image. Pull the close TD tag immediately to the right of the image code, not one line down. And you can use BR instead of the P style for more control.


• Avoid big image files above the fold. This is another classic sign of spam.


• Windows XP Service Pack 2 automatically (and helpfully!) strips images from some HTML email newsletters. The reason? Spammers often use 1x1 image tags to tell if an email account is 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 to understand reader preferences. Microsoft, in its infinite wisdom, blocks all images. The 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 the fake email, and use the familiarity of your email template and brand to steal personal data.


• Finally, notice I have not specified what version of the HTML and CSS standards to use. Use the simplest and lowest common denominator. Don't use CSS to layout your design, for example. And while use of HTML entities makes your code XHTML compliant, do entities work in every email software client? Be aware you have a choice. Use basic HTML wherever possible and use CSS to streamline your 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 point of view, however, the task of coding an HTML email newsletter can appear both simple and horribly complex. Hopefully I have described many of the issues and coding strategies that will work across email clients.

The best thing to take away? If you have to choose between a simple coding solution and a more complex solution, simplicity works better.

Our credits to the source/author of this article: Author: Tim Slavin Tim Slavin is the Publisher of ReachCustomersOnline.com, an online magazine that offers free how-to internet knowledge for budget-minded businesses and the designers, programmers, and others who support them. Tim and his wife run Red Horse Communications, a writing and internet consultancy. Online since 1988, Tim has done websites, email marketing, SEO, programming, and other internet projects since 1995. This article is taken from the ReachCustomersOnline.com website. Further reprinting prohibited

Source: http://www.reachcustomersonline.com