Standards for HTML Email

Previously I talked about how archaic the standards for HTML emails have been. Well, while things have improved a bit, they still aren't great. We are still looking at late 90s, early 00s for our HTML when creating email templates. Now we add to that the technology of smart phones and tablets. Our HTML emails now have to be responsive to a variety of screen sizes on top of working in multiple email clients.

Here are the general rules that any developer should be following to get their HTML email layouts to work for the vast majority of email client options. Since the email rendering engines vary depending on the email client being used, for example later versions of MS Outlook are using MS Word as their email rendering engine. MS Word does not do HTML well at all.

  • <table> instead of <div>,
  • Hex value colours should be complete (#FFFFFF) instead of abbreviated (#FFF),
  • padding instead of margin,
  • CSS2 instead of CSS3,
  • HTML4 instead of HTML5,
  • background-color instead of background,
  • HTML attributes instead of CSS,
  • inline CSS instead of style sheets or <style> blocks.

Source: Smashing Magazine

Since all email clients handle HTML slightly differently trying to have a consistent look to your email layouts is extraordinarily difficult, so for best results the K.I.S.S. ( Keep It Simple Stupid! ) protocol will give you the best results. The Smashing Magazine article goes into much deeper detail and has many suggestions to help with the construction of standards compliant emails.

When creating email templates, a good tool to use to see what the results will be for a variety of email clients is Litmus. If you send a substantial amount of HTML email, this service will be worth the subscription fees. At the very least try the 7-Day free trial to see what to look for when creating your templates. It can give you a set of steps to follow during your development process.

When it comes to a client who wants a super complicated and beautiful HTML Email design, it is important to supply the client with your knowledge by explaining these issues. We want our clients to be satisfied, but they need to understand that when it comes to email, functionality needs to come before design. If they insist, then sending the email as an image becomes an option, but other functionality will be lost. As long as you communicate this to the client, you've done your due diligence. Remember, you're the expert. Your client has hired you for that expertise. If they decide to ignore that expertise, at least you tried.

to blog