How to Code HTML Emails


One thing we stress is that in order to code your own HTML email, you  really, really, really need to know how to code HTML. You should be able  to code web pages "from scratch" without the help of any WYSIWYGs (like  Front Page, or even DreamWeaver). If you're that good, then you really  don't need to worry about a million little rules (like what CSS  definitions work in this email program, but not in that email program).  Just being able to understand "the fundamentals" will save you a lot of  time and frustration.

Coding Your HTML Emails: Fundamental Principles

An HTML email is nothing but a web page. So if you can code your own web  page, you can code your own HTML email templates. Only you've got to do  it the old fashioned way. Remember back in the 90's when there were no  WYSIWYGs yet, and you had to code everything by hand? Remember the  Internet Explorer vs. Netscape wars? Remember how you had to test your  work over and over and over again? HTML email is a lot like that. Times  10.

  1. The most important thing (if you wish to preserve your sanity) is to keep it simple. Focus on your message, not your craftiness.
  2. Images should be posted on your publicly accessible web server. In  your code, use absolute paths to point to them. Attachments are often  stored in randomly named temporary cache folders by some email programs.  They also hog a lot of bandwidth (especially when they bounce) so  attachments are not the way to go.Tip: One common mistake is to post  your image files on an intranet, extranet, password-protected server, a  secure server that's extremely slow, or a free hosting site (images may  not show due to bandwith issues). Post images on your fast,  public-accessible web server.
  3. TABLES and SHIM.GIFs are your friend. Keep it  simple, because email programs use different HTML rendering engines.  Some of them use Internet Explorer, Firefox, or in the case of Outlook  2007, Microsoft Word (what a headache!). Some of them use their own  proprietary renderers (Lotus used to do that, which is why you'll find  lots of old rants on out there about Lotus and HTML email problems).
  4. Don't code your emails too wide. Most people view  messages in their preview panes, which are narrow and small. Don't ask   if you should code for 1024x768 screens or 800x600. Please. This is  email we're talking about here. The preview pane in AOL 9 is less than  200 pixels wide. Think small. The most commonly used width for emails is  between 500 and 600 pixels and in some cases they are responsive so  they can break down into smaller sizes.
  5. Test how it renders. Your email will display  differently in all the different email programs out there. So testing is  a must. And we're not talking about IE, Firefox, and Safari. We're  talking about Outlook, Outlook 2007, Outlook 2003, Outlook Express,  Thunderbird, Apple Mail, Eudora, Lotus, Gmail, Yahoo!Mail, AOL, AOL Web,  Hotmail, MSN, Comcast, Earthlink, and on and on and on. How to cope?  Keep it simple. TABLES. 600 pixels wide max.
  6. Webmail services are deceptively tricky. Email  services that are browser-based, like Gmail, Yahoo!Mail, Hotmail, etc.,  will strip out your DOCTYPE, BODY, and HEAD tags. Makes sense---they  don't want your code to potentially override theirs. Anything you'd  normally code inside those tags (bgcolors, embedded CSS, JavaScript,  background music files, etc) will also get stripped.
  7. Think like a spam filter. You have to consider  spam filters and spam firewalls when you code. It's pretty obvious that  spammy words like "Viagra" or "V14GR4" will get you spam filtered. But  spam filters also look for stuff like, "do you have too many images, and  not enough text?" If you're sloppy with your code, you'll look like a  sloppy spammer.
  8. 99% of your CSS won't work (especially not in the  browser-based email services like Gmail, Yahoo!Mail, etc.). That means  no CSS-positioning, DIVs, etc. Before you ask me for a detailed list of  what works and what doesn't, just remember this (it'll save us all a lot  of time): When your email is opened in Gmail, for example, the CSS in  your HTML email could potentially override the CSS on the rest of their  page. So they disable a lot of it. Inline CSS is safer, and plain-old  style attributes in SPAN tags are safest. Or check out Premailer's CSS inliner tool.