The Little Guide to HTML Email

May 30, 2013

This guide was written a few years ago as a way to get some designers up to speed on (then) best practices for creating HTML emails. Most of the suggestions still hold true, but just be warned. I am actually working on writing a book devoted to modern HTML email best practices. You can learn more here.

Email Yay

Welcome to the wonderful world of HTML email! Email marketing is generally considered one of the more valuable digital marketing solutions. It is relatively cheap to produce and (if done well) provides a great return on investment. That sounds cool, but what is it like to actually build HTML email campaigns? For the modern web designer, it feels like stepping into a time machine and getting out in the late ’90s. Think of the time when tables ruled markup and all of your styles were inline. If you are like me and came of age in the era After Zeldman, then building HTML email can be a painful process. That’s why I took the time to write up this little guide and help ease some of that pain. Read on to learn about problems with HTML emails and how you can typically avoid them.

Why HTML Email Sucks

Most of the time I feel dirty. Really dirty, like a shower just won’t do. Maybe a firehose…Unlike some people, I don’t remember coding in the ’90s. I taught myself HTML and CSS as web standards were coming into play. As far as I am concerned HTML is for structure, CSS is for presentation, and Javascript is for behavior…and by god, you had better separate the three.

HTML emails, on the other hand, don’t work like that. If you remember building websites using tables and inline styles then you should be just fine with HTML emails. Think of the dirtiest, filthiest, most hacked together website you can from 1998 - remove the animated GIFs and marquee tags - and you basically have your standard HTML email. I’m not joking. The first reason HTML emails suck is because you are forced to use the most improper ways of building a website (which is all an email is anyways) and go against everything your modern mind tells you to do.

The second reason they suck so much is that they break. Constantly. And you will rip your hair out trying to figure out why. There are dozens of different email clients out there, and each one displays your markup differently. You aren’t just building a site for Chrome, Firefox, Safari and (ugh) IE anymore. No, no, life isn’t that good. Now you are building something that needs to properly render in GMail, Yahoo! Mail, Outlook, Thunderbird, Lotus Notes and 20 other clients. In multiple browsers, on multiple operating systems, and on desktops, laptops, phones and tablets. Yep, it’s not fun. But don’t worry, I’m here to help.

What You Should Already Know

This guide assumes that you know a few things. First, a little about how HTML email works. You can’t simply throw some markup into an OutLook message, CC 12,000 subscribers and hit send. Trust me, your subscribers won’t be happy, and your ISP will hate you. Good luck doing that 3 times a month.

No, you really should go through an Email Service Provider (ESP) that works with ISPs to insure deliverability. If you don’t you’ll probably end up in the spam folder or blacklisted. You should also know that HTML emails are sent as a Multipart/Alternative MIME formatted message. This means that your message is sent as 2 parts wrapped into 1. You are never just sending your HTML email, but also a plain text version as well. The MIME allows you to declare what type of message is sent in the email headers (i.e. text/plain for plain and text/html for html. Pretty easy, right?). You really don’t need to worry about this stuff though if you are using an ESP like MailChimp or ExactTarget. All you need to know is that the subscriber gets both your HTML email and a plain text version, which covers your ass in the case that someone doesn’t want an HTML email. Pretty cool, huh?

You should also know HTML itself pretty damned well. Know your tags, know how to properly structure a document, etc. If you don’t know HTML inside and out, go study it. Study the deprecated stuff too, as you will probably be using some deprecated tags that still work just fine with emails. Always strive to use supported tags and modern methods but remember - email’s pretty damned quirky, so you never know what you may need to pull out of your hat.

You should also be well versed in the intricacies of CSS. Understand your styles. Understand the Cascade and inheritance. Please, please, please don’t wrap everything in a span tag when the styles will inherit from something else. Understand that HTML emails are better served with inline styles over embedded styles, and you had better not use a linked stylesheet. I’m warning you…

Finally, you should know how to use Photoshop or a comparable image editor. Know the proper formats for saving images - what works with emails, what doesn’t, and how to optimize them. Keep your file sizes to a minimum, or else you may be hitting the spam filters. Oh, and keep your number of images to a minimum. The more images, the better the probability of triggering the spam filters. This is less and less an issue as time passes (check out Apple’s emails, for an example), but you may as well be careful.

Email Structure

The Structure Of An Email

OK, then. You have some awesome markup - nice, semantic HTML, divs with descriptive ids and classes, your css embedded in the head of your document, a valid doctype, etc. Everything is formatted nicely, your markup validates with the W3C, life is peachy. Now…throw it all out. Take a minute and go and grab a man’s drink. Scotch, Tequila, whatever. Then sit back down and get ready to have your mind destroyed.

We were a bit hasty. Let’s remove that HTML doc from your recycling bin, throw it back into your favorite text editor, and go through it to learn how to properly structure an HTML email.

Shall we start at the top?

So what have we learned about the structure of an email? You can screw using anything in the head: lose the doctype, lose any external stylesheets or Javascript, and throw all of your styles inline. Use tables for absolutely EVERYTHING. Oh, and make sure your images occupy their own table cells. Don’t rely on word wrapping or anything like that - it will only frustrate you.

Coding: Do’s & Dont’s

Let’s break down exactly what we should and should not be doing when coding HTML emails. This will just be one big list, so hopefully easier to digest than my verbose ramblings above.

Wrapping Up

That’s a whole lot of rules to follow, but I assure you that if you follow them, your life in the trenches will be a lot more tolerable. If you work where I work, then you don’t really get a whole lot of say in the overall design and layout of the emails. If you do get to design everything from scratch, a word of advice: Keep your layout as simple as possible, while still making it look good. Don’t use a ton of differently sized columns and weird, abstract layouts. It will make for a lot of markup and a ton of math. The simpler your layout is, the better. Clients will have an easier time rendering your document and there will be less that can go wrong.

A word on video in emails (as promised above). Don’t do it. It’s unreliable and you will hate yourself. Here are your options - Flash (won’t work), Quicktime (won’t work), Windows Media (won’t work), Animated GIF (wait for it…), Java Applet (won’t work), Embedded MPEG (won’t work). That’s right, the animated GIF is the only one that works. Of course, using this…Most subscribers won’t see it at first since email clients don’t display images by default, you won’t get sound, you can’t control playback as it starts automatically, the file size will be huge, and it probably won’t work on mobile clients. So there you go.

That about wraps up what I wanted to say about HTML emails. I hope you’ve enjoyed the journey. Good luck!