Since I mentioned on Twitter that I’ve been producing a lot of HTML email in the past year or so, I’ve gotten a bunch of requests for help in this area. This is because HTML email is a notoriously bizarre and unpredictable little subset of front-end development, and one can be a great web developer without having the faintest idea how to do an email that will work in most mail clients.
First, let’s get a couple of things out of the way. I’m not really interested in arguing about whether or not HTML email should exist; while I’m aware that lots of folks think it’s utterly loathsome and to be avoided at all costs, I’m also aware that it’s something lots of my clients want and request. So why not at least make an effort to do it well?
Ok. So what I’ve basically tried to do here is collect some of the little tricks and oddities I’ve had to learn while building this stuff. I’m not calling them best practices, because they aren’t, really – they’re just my practices. There are certainly other ways to approach email development, and plenty of them work as well or better than mine depending on what mail clients you or your company needs to support. Speaking of supported mail clients, here’s the list I’m using currently:
- Outlook 2003
- Outlook 2007
- Apple Mail
- AOL Webmail
- Gmail
- Yahoo! Mail
- Hotmail
For the webmail clients listed above, I support the following browser/OS combinations: Firefox 3/IE6/IE7/Safari 3 for Windows, Firefox 3/Safari 3 for OS X. And there’s also a number of clients I support sort of unofficially. What that means is that while they are not part of the normal testing process to which all my emails are subjected, I don’t use anything I know is unsupported in these clients, and I work around their bugs as much as possible. Here’s that list:
- Entourage 2008
- Notes 6
- Thunderbird 2
This combination of mail clients means that I’m pretty severely restricted in terms of what I can do when building an email. If you take a look at Campaign Monitor’s excellent 2008 guide to CSS support in email, you’ll see that there aren’t a whole lot of things that work in every single client on that list, and their list is pretty similar to mine. Essentially, most of the standard CSS techniques I would use when building a page for display on the web are not safe for use in email. What this means is that my approach to email development is entirely different than my approach to web development, despite the fact that they both involve HTML.
I care very deeply about semantic markup, standards compliance, accessibility, human readability, and all of those lovely things. That is, when I’m building a website. For email, I throw all of that out. My top priority for email is that it displays correctly in all the mail clients I support, and my second priority is that it’s still more-or-less readable before images are enabled (since images are turned off by default in many mail clients). For most web developers interested in standards, this approach sounds like heresy. It may help if you consider that many of the concerns we have when building websites simply don’t exist when building something as transient as an email. It isn’t going to get indexed by a search engine, for example, unless you do a web version as well – and if you’re doing a web version, use web techniques instead.
My basic strategy for HTML email is tables, tables, tables. And not the kind of tables you probably used on the web in 1998 – it’s even worse than that. Because I unofficially support Notes, I try to avoid making my tables too complex. This means I favor nesting instead of using colspan and rowspan because of their historically spotty Notes support. Notes also has trouble with too many levels of nested tables, but in practice I find that I rarely need more than five levels or so. The code this strategy produces is ugly as sin, but the resulting email will display correctly almost anywhere. Also, specify widths on all your tables, even nested ones that you wouldn’t think would need it – I’ve had trouble with Entourage and width-less tables.
The other thing I do that will be surprising and dirty-seeming if you’re used to good web development is that I rely almost exclusively on spacer images to position things, instead of CSS positioning (or cell padding, or line breaks). I stick each spacer image in its own cell and slap style="display: block;" on it. These latter two steps are not always necessary, but they avoid the once-in-a-while Hotmail and Outlook spacing problems that used to drive me nuts. Of course CSS positioning is more elegant, but none of the normal properties I’d use on the web can be trusted in email. So I’ve had to rekindle my relationship with one-pixel transparent GIFs. If you still end up with whitespace where you don’t want it, try stringing together your code and removing linebreaks where possible.
As for text styling, there are a couple different ways you can approach it. The CSS properties related to text are safer than the positioning stuff – font-family, font-size, font-style, text-decoration and such are safe enough to use. But because I like to be sure my emails will display without any CSS whatsoever, I slap the style attributes on font tags and on links. You can avoid using the dreaded font tag, of course, by slapping your styling on the relevant cell or what have you, but I actually find it easier this way and I like having the redundancy in just in case.
And that right there is the only CSS I’ll use in an email: display: block on images and text styling on font tags and links. That’s it. It’s almost beautiful in its perversity, don’t you think?
That about covers the tips I have as far as making sure your email will display properly in most mail clients. I leave the rest to your tinkering. As for making it mostly readable without images, this can be tricky if the email in question is a company newsletter or announcement, as many of the ones I build are. These tend to be pretty image-heavy. Nevertheless, try to use HTML text whenever possible. One thing that may take you by surprise here is the difficulty of using background images, at least if you support Outlook 2007 or Gmail. If you don’t, lucky you. But if you do, try to make sure the text bits of your email are on top of a solid color instead of an image, or at least be aware of what it looks like when the background image gets stripped out and adjust accordingly. For the parts that must be images, use alt attributes on anything with text in it. I also like to include title attributes on both the link (if there is one) and the image itself – it’s redundant but it also means you have a better chance of something being there if a recipient is looking at or mousing over your email with images turned off.
I could also write a lot about actually sending your email, and reducing its spam score, but for right now I just wanted to assemble some bits and pieces about email development itself. I will say that for deployment, it’s pretty tough to beat Campaign Monitor (and their blog is great, too). The rest will have to wait for another day.
If your job includes producing HTML email, I hope you have found this post helpful. And if your job has nothing to do with HTML email, I hope this post has made you thankful for that fact.
