Browse by...
Home Resources Blog

This article is a sequel to one that appeared on A List Apart shortly after the CAN-SPAM Act of 2003 was enacted. (If you haven’t read it, you might want to take a gander.) The web has made great strides in standards-coding techniques, and my philosophies have evolved accordingly. I now would like to clarify the intentions of my original article and explain how my approach to HTML emails has kept pace with the rapidly changing internet environment.


A spirited debate took place in the discussion forum for my original article. Many readers, dedicated to standards compliance, immediately denounced HTML emails as nothing more than vehicles for spam. Other readers disagreed, pointing out that while HTML formats are frequently used by spammers, they are also used by legitimate companies for permission-based email communication.

Both sides have valid arguments. But the sole intent of my article was to demonstrate how one could use standards-based markup for HTML emails, not to encourage spam or the use of HTML for general email communication. Like it or not, HTML emails are here to stay. And if we’re going to be asked to build them, we might as well do what we can to ensure they are built with accessibility in mind. As for spammers, I believe the likelihood of their dedicating time to learning techniques for standards coding is slim to none.</p

So for those of you ready to improve the markup of your permission-based HTML emails, let’s go to it. Following, is a screen shot of the properly rendered test email:

[screen shot of test email properly rendered]

My approach

Download example

Download a zip file containing the markup and images for the test email. (12kb)

For markup in the original test email, I utilized a blend of CSS and traditional techniques (Tables, etc.). Take the following markup from the original test-email whereby I used a Table for presentation [shudder] and a TD background to ensure the background would appear even in clients offering poor CSS support:

‹td width="28" background="imagepath"›‹img src="imagepath" width="28" height="25" /›‹/td›

This approach was a compromise, offering extended use of CSS and ensuring design integrity across the board. I have since matured my approach, however, employing fully-semantic markup (my standard practice for websites). Consider the following example:

‹div id="Title"›
‹h1›National Adoption Day‹/h1›
‹h2›‹a href="url"›Learn more‹/a›‹/h2›

In email clients lacking support for CSS, this degrades to an appearance similar to that of rich text:

[screen shot of test email with CSS disabled]

From my perspective, the result is perfection: beautiful designs for recipients with CSS-friendly clients and accessible, functional versions for everyone else. This, too, is a compromise, but only with respect to the integrity of the visual design. Accessibility is never compromised, and that’s the beauty behind this approach.

My testing suite

I surveyed friends and colleagues as to their email client of choice because stats on email-client usage aren’t published like browser stats. I tried to reach a broad demographic in hopes of using an inclusive suite.
The resulting suite comprised the following clients:

Desktop clients

  • Apple Mail (Mac)
  • Thunderbird (Mac/PC)
  • Outlook (PC)
  • Outlook Express (Mac/PC)
  • AOL (Mac/PC)
  • Entourage (Mac)
  • Eudora (PC)

Webmail clients

  • Yahoo Mail
  • Gmail
  • Hotmail
  • Squirrel Mail
  • AOL

Handheld devices

  • Motorola v551
  • Zaurus SL-5500

The results

By and large the clients in my testing suite offered pretty amazing support for CSS, barring the pitfalls noted below. Most of the desktop clients fared very well, but the webmail clients’ performance was all over the board. Considering the difference in environments, that was to be expected. Desktop clients have complete control over presentation, while webmail clients are dealing with an HTML page embedded within an HTML page. And each has its own unique method for handling this predicament.

Yahoo Mail alters the contents of an HTML email by changing things like ‹body› to ‹xbody› and adding an all-encompassing container DIV (#message) just inside the Body tag. The “xbody” issue disables all presentational aspects you’ve defined for the body of your document. There is, however, an accessible solution to this problem that minimizes gratuitous markup. Create your own container DIV that envelops your entire email and treat it as though it where the body tag. As for the new #message DIV, it’s relatively harmless
(at least in my tests) since Yahoo is considerate enough to add #message to any descendant selectors you might have applied.


#Title h1 {


#message #Title h1 {

Yahoo Mail does, however, attack with irreparable damage when it comes to positioning. Just as ‹body› becomes ‹xbody›, ‹position› becomes ‹xposition›.
Unfortunately, I was unable to find a workaround for this issue. The result is that positioned elements behave as if they were not coupled with any styles whatsoever. So unless your email list is void of Yahoo addresses, it’s best to avoid designs requiring positioning.

AOL (desktop client) accepts no background images whatsoever, whether CSS- or HTML-based. If a technique exists for forcing the rendering of background images, I am unaware of it. I suspect the culprit is their use of proxy servers, which already severely compresses images in favor of speed and at the expense of quality. The webmail client successfully rendered my test email, but I was unable to find statistics comparing usage of the desktop client with that of the webmail client. Outside of the background-image issue, both AOL clients successfully rendered my test email.

Gmail will function whether or not scripting is enabled in the viewer’s browser. A warning message is displayed when scripting is disabled, encouraging you to enter with scripting enabled. But the only differences I noticed between the two modes were as follows:

  1. Ads aren’t displayed with scripting disabled.
  2. The client’s GUI exhibited minor visual variances.
  3. With scripting enabled, the entire email is printed with JavaScript.

Irrespective of scripting settings, my test email was identical in appearance. And that appearance lacked any CSS support whatsoever. Gmail takes the liberty of stripping your styles and, “respectfully,” strips any trace of CSS having been used anywhere in your document. For example, it turned this:

‹div id="EmailBox"›
‹div id="Box"›
‹div id="Title"›
‹h1›National Adoption Day‹/h1›
‹h2›‹a href="url"›Learn more‹/a›‹/h2›
‹div id="Sidebar"›

into this:

‹h1›National Adoption Day‹/h1›
‹h2›‹a href="url"›Learn more‹/a›‹/h2›

Hotmail, too, strips out your styles but does retain the basic semantic structure of the document. And the primary difference between Gmail and Hotmail is that the latter supports inline styles. So, if for some horribly unfortunate reason you must ensure that your visual design is properly rendered in Hotmail, you can at least spend more time than you have available inserting inline styles.

.Mac accounts can be accessed using either the Apple Mail client or a web browser. Mail has seemingly flawless support for CSS. However, its web-based companion has a couple of major issues, depending on the browser used for access:

  1. Every email message is wrapped in a ‹font› tag, presumably to ensure that plain-text emails look pretty when rendered in their webmail client. This sounds reasonable until we want our CSS-based HTML emails to render properly. CSS properties for type selectors as children of HTML attributes should take precedence. Apple’s default browser, Safari, followed this rule. But in the extremely standards-compliant Mozilla-based browsers (Firefox and Camino) I used to test .Mac, the ‹font› tag commandeered the presentation. Helvetica is declared as the font, so if you’re using a sans-serif font in your design the damage is minimal. Alternately, you’ll need to consider how your email will render when serif fonts are converted to sans-serif.
  2. The message window is fixed to a width of 570 pixels. So if you want your email to properly render in this client, you’ll want to use either a liquid layout (variable or undefined widths) or a fixed width of less than 570 pixels.

Entourage has a peculiar problem that is solely cosmetic. It properly rendered the elements I floated but failed to apply their margin values. Margin was properly rendered elsewhere, just not in the floated elements.


HTML emails that contain semantic markup and CSS fare very well with the most commonly used email clients. And for clients that offer poor or no support, the semantic markup allows for graceful degradation. This amounts to ultimate accessibility for your intended recipients. My philosophy for internet communication is pretty simple: visual-design integrity for people with modern devices and browsers, and information integrity for everyone else. The adverse effects of forcing design integrity for everyone significantly outweigh the benefits for a very small percentage of internet users. Accessibility is king, and I believe that the system I have outlined is a good one for accomplishing just that.

This article was authored for Campaign Monitor by Mark Wyner of Mark Wyner Design, a small web design studio in Portland, OR, USA.

This blog provides general information and discussion about email marketing and related subjects. The content provided in this blog ("Content”), should not be construed as and is not intended to constitute financial, legal or tax advice. You should seek the advice of professionals prior to acting upon any information contained in the Content. All Content is provided strictly “as is” and we make no warranty or representation of any kind regarding the Content.
Straight to your inbox

Get the best email and digital marketing content delivered.

Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.


Get started with Campaign Monitor today.

With our powerful yet easy-to-use tools, it's never been easier to make an impact with email marketing.

Try it for free