Should you be sending HTML emails at all?
This is surely a debated issue, but ultimately I say if you have a message you feel would benefit from a nicely designed email you should go for it. If you just want to do it because everyone else on your block is doing it too, don’t. If you decide to do it, these are what I consider to be the five golden rules of HTML emails:
- Only send email to people that opted to receive them.
- Make sure to create it so that it looks the best it possibly can in all email clients.
- Don’t overdo it. Weekly is probably too often.
- Send a plain text alternative.
- Offer and opt-out link and honor it.
Update: This article is about a decade old as I update this. Probably not a great source of information anymore. A good source of information about CSS in in HTML email is Campaign Monitor’s guide.
WRITE your email before you design it
The first thing you should do is to write the plain-text version of your email. Doing this first, while you are fresh, will lead to better copy, a better plan for the design, and ultimately a better email. You will need to do this anyway, since one of the golden rules is to send a plain-text alternative to HTML emails. Sending BOTH a plain-text and an HTML email in one combined email is called the Multipart/Alternative email format, or MIME. Most email clients support it, it’s that thing that pops up that asks you if you want to send it plain text, HTML, or both, like in this Thunderbird screen shot:
Couple quick tips for your plain-text email: Hard-wrap your lines at 60 characters and write out full URL’s instead of using anchor tags.
Design for the lowest common denominator first.
After the plain text version of your email is done, then start thinking about design. Every single email client reading your email is going to have it’s own rules about how it deals with HTML emails, so you are going to have to design for the lowest common denominator. Think it’s a pain having to test websites in 4-5 different browsers? It’s much worse with email. Here is a partial list: AOL (multiple versions), Comcast, Earthlink, Gmail, Hotmail, Lotus Notes, Mail.com, Outlook (multiple versions), Thunderbird, Windows Live, Yahoo!, Mail.app. Not to mention mobile clients.
Assuming you have a fairly large list you are sending out to and have no idea what kinds of email clients they are using, you will need to think in terms of what you can’t do more than what you can do.
What you CAN’T do:
- Include a
<style>. Apple Mail.app supports it, but Gmail and Hotmail do not, so it’s a no-no. Hotmail will support a style section in the body but Gmail still doesn’t. UPDATE: In 2020, this is much better supported.
- Link to an external stylesheet. Not many email clients support this, best to just forget it.
- Background-image / Background-position. Gmail is also the culprit on this one.
- Clear your floats. Gmail again.
- Margin. Yep, seriously, Hotmail ignores margins. Basically any CSS positioning at all doesn’t work.
- Font-anything. Chances are Eudora will ignore anything you try to declare with fonts.
There are quite a few more things you should be aware of. For a great complete list of what online email services support what, check out this article.
What you CAN do.
In two words, inline styles. It’s not as awful as you might think, since we are basically developing a one-off email, inline styles are not nearly as egregious as using them on a website. Need a big green title for a block of text?
- The big can-do is images. Think creatively on what you can do with images.
- Since you will be using tables, think gridular. Grids are designers friends, there is lots you can do with a grid.
Tables are still the standard.
Take a look at the code of almost any HTML email you’ve gotten. I’ll bet ya it’s formatted with a table. Tables are still the best way to achieve consistent results across email clients. The email equivalent of the browser window is the “viewport”, or the area in an email client dedicated to showing the actual email. This varies quite a bit. A vary common technique is to set a table with a 100% width with a nested table inside of it that is centered with a static width. This seems to work very well. The outer table is also your big chance to set the background-color for the whole email. Too bad we can’t just use a div with auto left and right margins for centering, but it won’t work most email clients.
If you just don’t want to think about all these nasty inline styles screwing up your code and all the little rules of what will work and won’t work, don’t worry! There is a really nice (and free) preflight service out there called Premailer. With Premailer, you just design your email as a webpage (still think tables), then submit your URL. Premailer will parse the HTML and convert all your styles into inline styles for you, as well as give you a list of CSS warnings on things you are doing that might be dangerous and for which email clients they are dangerous. Handy!
They are also full-service HTML email marketing providers out there. Most noteably, MailChimp. With MailChimp, you design your emails right within their web editor. You still have a nice amount of control, the prefab template is pretty nice, and MailChimp will do everything possible to make sure the email looks it’s absolute best in all email clients. That alone is worth the reasonable rates ($30/month for lists up to 2,500 and goes up and down from there). MailChimp offers more though, a service which is almost invaluable, managing your lists for you. You get a customizable web page you can send people to to sign up for your emails, which will automatically add them to your list. Even better, they also handle unsubscribes automatically. Both of these things can be as transparent to you as you would like. Statistics on your emails are provided.
There is a free trial version for the service available. Even if you don’t end up ever actually using the service, you should check out MailChimp’s resource center. They have TONS of useful information on email marketing, technical info, and design tips. They even offer a totally free 64-page PDF called Designing, Coding, and Delivering HTML Email: A Beginner’s Survival Guide which is an awesome place to start understanding this stuff.
- Remember to use full paths to images, not relative paths. (e.g. http://www.yourserver.com/email/images/logo.gif). Also, link to images from your own server, not anyone elses.
- Check with your ISP before you go out sending thousands and thousands of emails, they might think you are a spammer.
- Test, test, and test again with as many different email clients as you can possibly get access to. You will definetly want to test the major online clients like Gmail, Yahoo, and Hotmail, but also definitely check Outlook, Mail.app, and as many other desktop clients as possible.
- Don’t go over 600px in width. Even that is pushing it. If your design can handle it, 440px is closer to ideal.
- Think of any extra CSS you may use as upward-compatibility. You can always include some header style CSS if you want, but think of it as a bonus for people using email clients that support it. Then turn it off completely and make sure the design still makes sense.
- Try not to look like SPAM. Pretty obvious, but just writing good code and honest copy should keep you out of the can here. Your HTML email is definitely NOT the place for a Viagra joke.
- Just like in web design, it doesn’t hurt to think above the fold. Meaning what users will see before they have to scroll.
- Use your footer like a footer. This is a great place for lots of things including phone numbers and addresses, about information, unsubscribe options, and perhaps a little reminder of what this email is and why the reader is on the list.
- OBEY THE LAW. The CAN-SPAM act became law on Jan. 1, 2004. It says there many things you must do as a commercial email-er. Highlights are basically don’t be deceptive, and that you MUST include a physical mailing address as well as a working unsubscribe link.
All of these are fairly effective examples I think. Papa John’s is an offender for way-to-often emailing, but their emails are usually pretty enticing.
I would probably add in the Quick tips that if you are going to using images make sure you use alt tags. I know in Gmail and Outlook, unless you are a trusted source, it will not show the images till you say to show images. So, most likely you will have a blank spot and if there is nothing to grab the user, the will just delete.
That is a super good point and very important Benjamin. Since you are the first comment I think people will read it and I’ll let the post alone.
Better you update the post and credit to him with a link that scrolls to his comment :)
That’s true what you have said about images, but what about attaching those images to email? Attached images are displayed by gmail and Thunderbird automatically (I don’t know how it is with other MUAs).
Nice writeup Chris, especially the emphasis on aiming for the lowest common denominator. Unfortunately email clients like Outlook 2007 and Gmail make purely CSS based emails almost impossible, but if you’re dabbling in a little CSS I’ve tested what’s supported in all the popular email clients.
@Dave Greiner: Great link, thanks! Very comprehensive research there. The PDF you provides is especially handy.
I’ve been developing HTML emails for a living for about a year now, so I can say that there is some pretty good advice in here. I started out trying to write clean, table-less code, and let me tell you: it isn’t worth the hassle. Use tables. Use them nowhere else, but use them in emails.
And I would emphasize: thinking above the fold is very critical… and you don’t have as much room above the fold as you’d think. Remember that a lot of people rely upon preview panes to view their email… or consider how many ads Yahoo stick above every incoming message. You’re working with about 300 viable pixels above the fold.
I know this post is old, but I wanted to reply to this in case anyone reads upon your comment. Just because tableless layouts are the “new” standard doesn’t mean there’s no need for tables anymore.
There is 1 case where you should absolutely use a table everytime…and I’m surprised how often rookie designers don’t do this. Use a table when you are trying to display tabulated data!!!!!! Please!!!! Don’t emulate a table with divs!!!!
Okay, 2 cents contributed to a comment that probably won’t get read…but hey, I read it.
Great article on how to create great html email
Aaarrrrgggghhhhh I hate html emails…
BUT yes they do have a place. Best tip I know is to create simple html emails, KISS
Check out the Emogrifier, a PHP utility we developed that converts HTML & CSS into gmail friendly emails. You can use it on the web site, or you can download the PHP code for your application. We decided to open source it to help out developers like ourselves who were struggling to get emails to look right in gmail.
GMail, why hast thou forsaken us?!
I’ve also finally released a CSS-to-Inline converter that may be a balanced solution. It comes as a web form or a PHP script that you can download. I didn’t want to open source it just yet, though!
It is simpler than Premailer and more powerful than Emogrifier. It takes just your CSS and HTML and spits out your new code. It also honors CSS multiple rule (comma-separated) declarations, ordering, and precedence.
Check out the fully functional trial for $1.
we are sending the notify mails to customer in that mail we want to expand and collapse button and based on the click we want to show text. is that possible using the styles. Please do the needful.
Some browsers, mail clients (browser based and desktop based) will support your needs differently.
Since you would need to use pseudo selectors to get the desired result, support would be patchy, mainly because pseudo selectors must be declared inside a block or ed stylesheet.
Click my name on this comment to checkout my blog and message me if you would like more info.
It took me a while to find this page of supported CSS styles in email browsers: