HTML Email Specifications and Best Practices - a year later

So it has been a little over a year since my last post about email standards. It's about time for an update. In my latest look at the Email Standards Project there have been some improvements by some of the email clients. The majority are now getting excellent ratings, but some of the older clients are still not getting it right. In the case of Outlook 2007, which is still used by the majority of users with older Windows systems, they are still receiving a poor rating. Frankly, we can't expect Microsoft to change this email client anytime soon. Their latest email client, Windows Mail, has received an excellent rating. This fact, I would suggest, may point to the coming demise of support for Outlook.

Like Outlook 2007, Google Gmail also / still has a poor rating. This is slightly surprising considering how dominant Google has become in the internet world. It is hoped that Gmail will soon be on board with these standards soon. Even Windows Hotmail is getting a better rating than Gmail with an "average". Apple Mail, AOL Webmail, Eudora, Entourage, and Mozilla Thunderbird are now full supporters with Excellent ratings.

For those of you who need to develop email templates for clients who use mass-emailing services like Emediatemail (our own email campaign application), Constant Contact, MailChimp, etc. These standards are what you need to keep in mind while coding your templates. The Email Standards Acid Test is the expected functionality / display HTML and CSS standards that we want all mail clients to achieve. As I mentioned in my previous post about this subject last year, the HTML and CSS that can be used for email clients is far more limited than you would find in a standard web browser. The acid test on which the standards are being tested are for proper implementation of many of the basic CSS elements that have been covered in web design for years. These standards, if followed, will allow for more flexibility in email design if not functionality.

Some of the basic design capabilities we take for granted in standard web design are just not available in HTML email development. While this may seem frustrating, remember that it is an email that is being sent. It isn't a web page or web site. It doesn't have to do all of the things that a web site does, and it shouldn't. The templates that we build for these mass email tools are meant to provide a nice display for what is essentially an email message.

In terms of dimensions for the display of HTML emails, not much has changed. We still need to aim for that really limited internal display area of most email clients. 600px wide is the number we're still after. While opening an individual email into its own window would allow for a wider display, we need to keep in mind that most people view their emails in the client email preview window. The position of this preview window can vary from program to program and can even be repositioned in some email clients. Therefore, it is important to keep a specific standard width to accommodate the most email client browsers.

To long to read? Try this summary:

  • Aim for a 600px wide design template
  • HTML tables still used for layout
  • No overlapping blocks of content due to HTML table limitations
  • Avoid javascript programming - email clients aren't web browsers
  • No transparency or transparent graphics
  • To achieve beautiful layering effects you need to rely on a complete rendered graphic
  • CSS 2 & 3 standards are only slightly supported so should be avoided

So, with generally better email client support we should be seeing more consistency among displays. But that completely depends on designs that are put together with these standards in mind.

to blog