The Little Guide to HTML Email

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.

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.

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?

First, lose the doctype. Actually, lose everything in the head. That’s right. Take note of all of your CSS so you know how you want everything to look, but just delete it. Why? I’ll tell you why. Because a majority of email clients today are web-based. People like checking their email online, through a browser. It’s convenient: no servers to set up and maintain, doesn’t take up space on your hard drive, and you can check it from any computer. But guess what? Web clients will strip all of that stuff out of your document as soon as it hits your inbox. They don’t want anything overriding their CSS, Javascript, or whatever other voodoo is up there, so they drop it. That means that you can’t throw anything up there and reliably have it displayed to all of your subscribers, so just cut it out from the beginning. Some clients will display CSS in there, but it’s not reliable, so drop it. Inline styles are the way to go.

Tables are King. Start at the body and work from there. Going down, do you see all of those divs you used? Yeah…you’re going to want to get rid of those, too. Again, a lot of clients support divs, but it is inconsistent, so why bother? We want our customers to see the same email (or as close as we can get) in any email client. So what will we use instead? Tables. That dreaded, feared, horribly misunderstood relic from a bygone age. In the world of HTML emails, tables are king. Pretty much anything you have in your email will be contained within a cell, within a column, within a row, within a table. Get familiar with them, and learn to love them. You will be nesting tables, so please learn to use some math and explicitly declare as much information as you can about the table, rows, columns, and cells. Width, height (if you can), etc. Oh, try not to use too many columns though, or nest things too deeply. Big Bird might like it, but Lotus Notes sure as hell does not.

HTML5 is sexy. We will not be using it. You may have been reading up on all of the HTML5 goodness lately. All of the new tags they have included - header, section, articles, aside, nav, etc. They are beautiful and semantic and make your tummy feel warm. I know, my tummy is warm just thinking about them, too. Stick to XHTML or HTML 4 though. Most clients have pretty shoddy support for HTML5, so we may as well not bother. Besides, we will be using tables for everything anyways, so no worries, right?

Inline EVERYTHING. You can drop all of your specified selectors, too. Your ids and classes can just be deleted. You will be sticking to inline styles declared for your tables, table cells, paragraphs and spans (when necessary). You won’t have any embedded CSS or an external stylesheet, so those are just adding weight to your document when it’s not necessary.

No Javascript. Finally, don’t even think about trying to use Javascript in your emails - won’t work. So if you have any scripts in the bottom of your email, get rid of them, please. Those one’s at the top are already gone, remember? We deleted them right after we threw some scotch in our bellies.

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.

Use tables. For everything. A container table for the whole email. A table for most elements in the email. Everything in their proper table cells. Rows are good, I would probably avoid columns though - they force you to use colspan alot and some clients don’t really play well with colspan.

Nest your tables. In most cases, nesting is good. But, don’t go too deep. Think more Big Bird, and less Cobb from Inception. Too deep and you will get lost in the limbo of Lotus Notes, never to return. A good rule of thumb is about 2-3 levels, no more.

Use individual tables for large images. When you have a large image that is sliced into multiple images (for different links, etc.) then try putting each image, or row of images, into its own table. Don’t put everything into the same table and just rely on rows - I have seen GMail break this kind of stuff before, not cool.

Speaking of images… Use the ‘Display Hack’ on all of your images, just to be safe. Gmail and Yahoo! Mail are infamous for this. If you have images butting up against each other, they will separate them and add a white space between the images. It looks like a steaming pile. To fix this, simply include style=”display:block” in all of your image tags. If you have multiple images in separate cells within a row, I also recommend explicitly declaring the width in the td tag.

May as well make it a rule. Scratch that last recommendation - let’s just always explicitly declare the width of a table cell.

Again, with images… Always explicitly declare the image width and height in the img tag. ALWAYS!!!

Background Images. It used to be, “Don’t use them”. Now, you can, but I still wouldn’t. And if you do, always provide a background color as a backup plan, so your design doesn’t suck when your background image doesn’t work.

Don’t even think about video. Flash, Quicktime, Java, nothing…You are stuck with animated GIFs and I wouldn’t recommend those either. Read the next section to learn why.

Inline CSS. We’ve been through this before, the title says it all.

CSS Positioning. Don’t use floats, CSS positioning is flaky. Use tables. I can’t say it enough.

Don’t use shorthand. Try not to use shorthand for your CSS properties. Instead of something like font: 12px, Helvetica, Arial, sans-serif; declare each of them separately in your inline CSS. A lot of email clients don’t support shorthand properties, so cut it out! I know, it sucks and looks ugly, but I’d rather have your markup look ugly than your email look ugly when it is displayed in a client.

Speaking of fonts… Stick to the normal, web-safe ones. Nothing fancy, and don’t even attempt to use @font-face, it won’t work. Thinking about using Google’s Web Fonts service? Think again, Javascript will be stripped, son.

Picky about links. If the design calls for specific link colors, you are going to hate yourself. And feel redundant. Most clients will override the link colors to the default hypertext blue unless you specifically declare it with an inline style in the link tag itself, or have a span around the text of the link. Some people prefer doing both ways, which is good to be safe. But you can usually get away with just doing the span.

Absolute Paths. Always, always, always code links with absolute paths to a URL on a public server.

ALT Attributes, please. Always include something in the alt attribute for your images. Be descriptive without being verbose. Most clients don’t display images by default so the alt text will be all they see. It looks spammy when you don’t include it. If you have image borders or shim gifs (I know, I know…) then you don’t need to include anything - but anything with content gets them.

Watch your width. Be conscious of your email’s total width. Most clients display your email in a preview pane, and usually it’s not a very big one. Having a super-wide email will look like crap and force your users to do a lot of horizontal scrolling. It really pisses people off. So stick to a pretty narrow width for your emails - usually with a max between 600-650 pixels wide. This is becoming even more true with mobile browsers and email clients. The iPhone and iPad are pretty good with displaying HTML emails (although their text resizing sometimes sucks), but you will want to bash your own head against your desk when you try to read a wide email on an Android phone. Keep them narrow and simple.

Test, test, test. However you need to, make sure you test your email in as many clients as you can. Sign up for all the web clients, get an extra box with some desktop clients if you want, or just pony up for a Litmus account, but test your emails as widely as possible. You will be surprised with what they look like in some clients, but that’s how we learn and figure out what works and what doesn’t. It also helps you to develop good templates to work from, so you don’t have to code the same markup over and over.

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!

Like this? Get email updates for more.

Subscribe to The Intermittent Newsletter, an occasional email newsletter about email (so meta), the web, coding, design, writing, and a whole bunch of other stuff.

NameEmail

Jason Rodriguez is a writer and designer helping people better understand the value of the web and email—usually through writing, speaking, and teaching.