HTML email - you either love it or you hate it. Some love the simplicity of text-only emails, while others praise the flexibility and good looks of HTML. But it doesn’t really matter whether you love it or hate it because sooner or later a client will ask you to design one of those ‘pretty looking email thingies’ for their own customers, and then what do you do?
Most of us tend to think that if we can design a web page, then hell, an HTML email will be a piece of cake! Well…almost. But before you decide to plunge into HTML email design head first, there are a few guidelines to follow that can ensure the best results for you and your clients.
The guidelines fall roughly into these recommendations: how you should design your email, how you should code it and finally the essential content you should include. Before we get into it though, let’s get one thing settled once and for all. These guidelines are for relevant, permission-based emails being sent only to subscribers who have opted in to hear from your client specifically on the topic of the email. So if you’re a spammer, look away now!
Design for images being turned off
Here’s a nasty little fact for you. Any of your recipients who use AOL, Outlook 2003, Outlook Express and Gmail will never see the images in any emails you send them by default. For some people that can make up at least half of all the people they ever send email to. Bummer huh? I told you it was nasty.
Apple iTunes Announcement
Here’s an example of just how ugly things can get. It’s an email I received from Apple announcing the launch of the much anticipated iTunes Australia Music Store.
The Apple HTML email I received with images turned off
The same email from Apple with the images turned on
Luckily I recognized the sender and enabled the images right away, but how many of their recipients got the version without images and deleted the email immediately?
We know that images get blocked and that this will affect the design of your email - but blocked images are by no means a show stopper. All you need to do is follow a few simple guidelines when designing your email and you’ll forget that image blocking was ever an issue:
- Don’t use images for important content like calls to action, headlines and links to your web site.
- Ask your recipients to add your sending address to their address book every chance you get. This will ensure your images are displayed by default in a range of popular email environments.
- Add a text-based link to a web-based version of your email that will reveal your email in the browser in all its glory.
- Use alt text for any images (which will be viewable in some email environments, especially Gmail).
- Make sure you always include the width and height in the image tag for every single image. This ensures the empty placeholder images don’t get stretched and completely throw your design.
To backup these recommendations, here are a few samples of emails that have been designed with these guidelines in mind. Notice how readable they are even with images disabled.
Digital Web Magazine’s Newsletter
Designed by Mark Wyner, this email even uses a clever image replacement technique to display a text alternative when images aren’t enabled. It looks great and is easy to read in either state.
Digital Web Magazine’s Newsletter without images
Ta Da! The same newsletter with images turned on
River City Church Newsletter
Designed by Jon Livingston, this email looks great with images enabled, but the large, clear title in the header still makes it recognizable to those with images turned off.
River City Church newsletter with images on
River City Church newsletter with images off
Remember that almost half of your recipients may be using a small preview pane to decide if your email’s really worth checking out. Preview panes allow your recipients to check out a sample of your email before they decide to open it and read the whole thing. Some of your recipients will even read all their email in the preview pane and will never completely open it.
Historically, preview panes have been popular among traditional email clients like Outlook and AOL. That’s all about to change with the two most recent betas of the new Yahoo! Mail and Windows Live Mail (Hotmail) both sporting a split-screen preview layout.
So how does this sudden loss in screen real estate impact your design? We’ve all got busy inboxes and if you’re like me, you’re pretty trigger happy with the delete key. If your design doesn’t grab your recipient’s attention with relevant and interesting content within a second or two, it probably doesn’t stand a chance.
Each email environment dedicates different screen real estate to their preview panes, but no matter what your recipient is using, try to ensure the following:
- Include something that will identify you and even attract interest at the very top of the email and preferably to the left. This could be a summary of the email content or at the very least the name of your company/organization.
- Check out your reports after each email you send to see what people are most interested in - try to make that visible in the preview pane for the next email.
- Make sure this content is text-based so it will be viewable by all recipients by default.
CSS or tables for layout?
Ahhh… the age old question. Unfortunately, the answer is still ‘it depends’. Contrary to popular belief, fully-semantic CSS based emails are not only possible, but widely supported in the majority of email environments. Even better, if you code your CSS correctly, your email can fall back to a perfectly usable rich text email for those with poor CSS support.
Today, deciding on whether to play the CSS card or fall back to tables and inline CSS is a lot like the days when you had to decide if you wanted to support Netscape. Some clients will demand it, while others realize that it’s time to move forward.
If you’re unlucky and the CEO uses Lotus Notes but wants your design to look consistent for everyone, tables and inline styles it is. If you can explain to your client just how broken some email clients are, and that your design will be accessible by everyone but will degrade to a simple layout for some, CSS is an option.
At Campaign Monitor we’ve tested CSS support across every popular email environment out there, so if you’re interested in which CSS selectors and properties are supported, it might be worth a peek. Your clients’ preferences aside though, it’s impossible to know what email environment your recipients will be using. Ultimately, to decide on CSS or tables you’re going to need to make some assumptions.
If you’re sending a Business to Business email, it’s safe to assume that most of your recipients will be using Outlook (around 75%) or Lotus Notes (9%). Outlook’s CSS support is top-notch, but Lotus is just plain dismal. That one’s your call.
If you’re doing the Business to Consumer thing, you’re probably looking at Yahoo!, Hotmail and AOL. If you’re targeting early adopters, you should also consider Gmail (although be warned, Gmail is not as popular as you think it is and is still only hovering at less than 5% of the web-based email market).
To make things easier, here’s a quick summary of which popular email clients support the CSS approach, and which ones rely on tables and inline CSS to display your message as intended.
| Email client | What you should use |
| Yahoo! Mail | CSS |
| Hotmail | CSS* |
| Gmail | Tables and inline CSS |
| Outlook and Outlook Express | CSS |
| Lotus Notes | Tables and inline CSS |
| AOL 9 | CSS |
| Thunderbird | CSS |
| Mac Mail | CSS |
| Entourage | CSS |
| Eudora for the Mac | Tables and well, no CSS |
* Hotmail has one big gripe - make sure you include your <style> element in the <body> and not the <head> or it will be stripped completely.
I want to reiterate this point because I think it’s so important. Don’t be ashamed if you’re forced to go down the tables and inline styles path. As I mentioned before, email clients today range from perfect CSS support to almost none. If your client demands design consistency for all recipients, you really don’t have any other option.
Five Things to Avoid
Whether you use CSS for your layout or not, there are a few other big no-no’s.
- Include the
<style>element in your HTML file, don’t reference it externally. Some providers will strip it altogether, while others won’t use it if images are disabled. If you’re sending to Hotmail recipients, place the<style>element in the<body>and not the<head>. - Avoid using CSS for positioning. The support is very limited and will more than likely result in a broken layout for most of your recipients.
- Don’t use Flash or JavaScript. Flash is poorly supported by most email environments and JavaScript will either get stripped or a security warning will be displayed to your recipients.
- Make sure you properly format your HTML and CSS. Leaving a tag open or overly messy HTML may result in your email being filtered as spam.
- If you’re targeting Gmail, make sure you do your CSS inline, the
<style>element will be removed completely.
Don’t forget to test
No-one launches a new site without checking it in a few browsers first and the same applies with your email designs. If you’re sending a lot of HTML emails, you should try to test each new design in the following environments before sending:
- Web - Hotmail, Yahoo! Mail and Gmail
- PC - Outlook, AOL 9, Thunderbird and Lotus Notes
- Mac - Mac Mail, Entourage and Eudora
The only one you’ll need to pay for out of all of the above is AOL, but they have very cheap plans perfect for testing for around $5.95 a month. Also, you can always send it to a friend and get them to test it for you.
Don’t forget though, once you get your email right, you can generally re-use your template design and just add new content, so you’ll only need to re-test occasionally.
Essential content
On top of getting your design and code right, there are a number of items that you must include in your email content. We’re not mucking around here, these are protected by law (at least in the US) and can land you in a whole heap of trouble if they’re not included.
The Must-Haves
- A working unsubscribe mechanism. You want to make it as easy as possible for your recipient to stop hearing from you. I recommend a single-click unsubscribe link.
- Your company name and physical address.
The Should-Haves
- A link to a web-based version so those having trouble viewing your email can check it out in their browser.
- A quick summary of how you got your recipient’s email address (they opted in from your site, they bought a product from you, etc).
- Your recipient’s email address, so they can verify that the email was specifically sent to them.
- A request to be added to your recipient’s address book to ensure images will be displayed by default.
- A text-only version of your email. Some of your recipients may set their email client to only show the text version of each email, so make sure send your email in multi-part format, which includes both the HTML and text-only version in a single email.
By following the guidelines mentioned above, you can ensure the best email experience for your recipients and hopefully the best results for your client.
Like this article? Digg it!
What a great article. As someone who spends a large chunk of the day creating HTML emails I can really appreciate this article. You have managed to sum up all the important info into a short article as opposed to the 40 page manual I was sent by my email client.
Thank you for this article, it’s very useful.
Tech Tip: HTML E-mails - Taming the Beast…
Another helpful article from Vitamin on creating great HTML e-mail messages….
This article is great! Though this is just one piece to the puzzle of managing mass email, its a very vital and important piece! Thanks for all of the examples, screenshots, tips, and hints!
Peace,
Nate
I would like to see a “part 2″ to this article, dealing with some of the issues in making sure the recipient actually receives your email. I have struggled for years with all the black holes that HTML emails can be sucked into. I’m not talking spam, either, but company newsletters and simple user validations. There are a number of factors to consider: correct HTML, correct headers, client spam-blockers, and draconian black-lists.
I design and send out newsletters for the company I work for. I am perfectly capable of designing everything by hand, but I do try to make it as friendly and streamlined as possible via Dreamweaver version oldoldold.
A problem I had was finding a decent way to send html emails out. We are an outlook environment, which needlessly clutters up sending an html email. I picked up a program called Dynamic Mail Communicator, but I fear it adds to the overall spam score by being what i assume is a spam tool. I briefly used a mailing list program (mailman) but that proved cumbersome.
What would you recommend for composing and sending html email? I have linux, windows and osx to choose from and don’t mind spending money.
Very instructive article. Thank you for sharing this with us.
Excellent. Taught me a few things I didn’t know.
Remember having to find all this out for myself a few years back, bit of a nightmare in reality.
Excellent article, just what I was looking for, excellent timing! :-)
Hey Eric, why don’t you try David’s company Campaign Monitor. I’ve used it before and it is great. The price is very inexpensive and they provide all sorts of feedback for you, such as the open rate, bounce rate, click through rate, etc.
Great! Thanks. One thing I have always wondered: when sending html emails out of Thunderbird, whats the best option: HTML only or HTML and rich text? My limited testing has produced no clear results across different clients…
[…] Design CSS : HTML Emails - Taming the Beast […]
This article astounds me! I can’t understand why someone would put so much time into something that folks will never, ever see!
My position on HTML email is simple: I don’t read it. Period. If you were smart enough to include a plain-text version, then I’ll take a look, but pretty colours, bling and such have no place in the plain-text world of email. As far as I’m concerned, if you don’t have the skills to communicate your message in plain text without bling and flashing lights, then you’re almost certainly a spammer, and your message isn’t worthy of the time it would take me to decipher it.
I got the wierd no-content message claiming to be from Apple too, I reported it to spamcop, bluefrog, et-al as spam.
I configure every email client that I install for my customers to quietly ignore HTML email.
I would move the “A link to a web-based version” point onto the must-have list.
@ Peter Newpiper
Dude get with the Naughties, its not 1980 anymore…
HTML emails have their place in the world of communications and they can benefit the readability of emails massive amounts depending on how much and what sort of data you need to display in the email.
Sure if you’re just writing to yourself saying “Peter you’re such a big boy” then you don’t need HTML but there are lots of reasons why HTML is preferable.
And configuring your customers email clients to obey your sick and twisted nazism-of-HTML-email’s rules is just childish.
If it doesn’t include a text version, I’m not reading it. The real lesson to teach companies is that they should always include a text version. If not, I consider it spam. There is absolutely no excuse in this day and age.
And another thing - make sure that text version also gives the unsubscribe info!
Thanks for the great write up David. Articles like this make Vitamin a must read site. Cheers.
Great article! Thanks for the tips! I had to go through this process myself last year and it took much longer than it should have to make all of the CSS work in all of my clients’ e-mail programs.
@ Peter Newpiper
While I completely disagree with your opinion on HTML e-mails, you have every right to have it.
I would, however, caution you about imposing that kind of mentality on your customers (likely) without their knowledge. It’s one thing for you to do this to your own e-mail since you are entirely aware of what you might be missing. It is another thing entirely to do that to people that do not know any better.
Nice article, but I would have liked to have seen some more information on the nitty gritty details of things like mime-multipart-alternative content and how to include images as attachments and link to these attachments so that webbug (http://en.wikipedia.org/wiki/Webbug) sensitive clients will still be able to show the images. Also some information about how to structure things so that they degrade gracefully would have been very welcome.
… and Oli invokes Godwins law, and the rational discussion is over. Nice one.
Peter, Godwin’s Law really is unamusing rubbish. Don’t be so silly.
Great article. Especially like the compaitibility table.
I send out invoices and instructions out in HTML (multipart w/plain text alternative) as well as semi-monthly newsletters.
I too consider HTML email the devil’s work, however, but that’s what people like. Personally, I set T-Bird to allow me when to view HTML and images in email, so that works out well.
And this is yet another unsolicited testimonial for CM. ;-)
We use them and they are great!
To Peter, while it’s true that HTML can be abused for emails that doesn’t make it bad by default.
It’s a bit like the debate over the use of Flash on the web - too much is a bad thing, but used properly (i.e. sparingly) it can be a great tool.
A properly design HTML email can be a lot easier to read than a pure text one (just look at the Digital Web example above). Headings can be made to stand out, emphasis can be placed appropriately, and so on.
I’ve seen plenty of bad text emails where it’s hard to make out where one section ends and another begins. So, it’s not a given that a pure text email will be easier to read.
[…] HTML Emails: Taming The Beast from David Greiner on Vitamin. […]
Great comprehensive article. Perhaps the one thing you missed was getting the email through Spam filters. This is certainly a consideration of any HTML or text email and ensuring the message is well-formed and has the correct headers is imperative.
Great article. As a matter of fact, one of clients asked me to do this just this week! ++Thanks.
CSS vs. Tables in your Email Communications…
David Greiner has a great article on the thinkvitamin.com site describing when to use CSS and when to use html tables in your email communications. He also discusses issues with images and the preview pane and outlines capabilities in various email cli…
CSS vs. Tables in your Email Communications…
David Greiner has a great article on the thinkvitamin.com site describing when to use CSS and when to use html tables in your email communications. He also discusses issues with images and the preview pane and outlines capabilities in various email cli…
Seconds before i check my feeds from digg i was talking to one of my friends about this very issue for a newsletter he is putting together, Thanks a lot!.
I still have serious reservations about use of CSS in emails. Compatibility is still a huge problem. Hotmail removes certain attributes altogether, from memory I think it includes top and bottom margins.
Having to put all your CSS inline seems like a lot of work for not much benefit. We need to think about why we want to use CSS in the first place. We are not separating presentation from content and could even end up producing more markup than if we had used a table layout.
Great article! Now I’m gonna go spam everyone! muahhahaahh!!(&*Y*#&@
*kidding*
[…] HTML Emails - Taming the Beast […]
Great round up David.
[…] Should you use CSS or (horror of horrors) tables? And what do you do when images are âblockedâ?read more | digg story […]
To even think that tables is a horror shows that you spend too much time writing articles in academia and not enough time writing production code in the REAL world.
To use CSS tables in a single HTML e-mail is just plain stupid as it’s only a single page.
Separating content from layout is even more shortsided as it’s only a single webpage anyway sent to the user ONE time only.
So, not only is the page using css tables larger and requires more bandwidth, the chance of this page displaying incorrectly is even higher as now you have no idea how wide the user will set their e-mail software at, Not everyone maximizes their e-mail client or browser even though the have a new 19″ monitor.
Here, have a look at this link so users out there aren’t bombarded with all this css mis-information.
http://www.decloak.com/Dev/CSSTables/CSS_Tables_01.aspx
David,
Thanks for this great writeup. As others have said, email communication add tremendous value to any company and this article adds tremendous value to anyone looking to get their feet wet with customer correspondence as well as to Vitamin.com.
Thanks again and keep up the great work.
[…] Keeping all of that in mind, there’s a great post on Vitamin by David Greiner of CampaignMonitor.com that discusses HTML emails, their viability and their pitfalls. While FileMaker doesn’t have the ability to send HTML emails, it can obviously send email through your default email program on either Mac or Windows. The article on Vitamin provides some great pointers on how to set up a good and compelling email that doesn’t get bogged down by the user’s email security settings. Here’s a snippet of some of the guidelines provided in the article, to whet your appetite: […]
Here is another voice for plain text. If the message is only in HTML I mark it as spam. If there are external images to load, I mark it as spam. If images are sent with the e-mail, I blacklist the domain.
Thanks!!! Great article. Helped me a lot.
[…] Fr alle die es trotzdem nicht lassen knnen, beschreibt David Greiner in einem Beitrag was beim erstellen von HTML E-Mails zu beachten ist. […]
I also would like to add a point that ideally the email should either (1) scale to width or (2) if fixed, not be set wider than 550 px in width. Email clients have side bars that take up much more desktop real-estate than a browser. I have seen fixed HTML designs set to 650 px etc and then for that dreaded horizontal scrollbar to appear is a big no-no!
I also think better clarification within this article should have been given much earlier as to the CSS issue. You mention only near the end the fact that it’s CSS-styling at this time only, not CSS positioning. Throughout the article I thought the latter was possible, contrary to my production experience! Not so, it’s basic inline styling only.
Also I have found an issue with graphics set to tile across a table / cell, using the ‘background’ property. Simply doesn’t work in many clients. I’ve had to get nasty by creating individual cells and using a simple background colour instead.
All of the content within this article I was aware of, but nonetheless, worth keeping on file for reference… well written!
The other point I thought I’d share was that linking to graphics on a server, in my experience, is a far better method to use for the sake of compatibility. Outlook & … Express encode the images into a sequence of ascii numbers (not sure of the exact terminology of format in use) and most online clients can’t decode this.
The drawback is for the viewer on a dial-up connection. Often the connection will disconnect after retrieving the email (based on preferences), which - in this case - isn’t complete: images still need to be downloaded. But then most nowadays have permanent connections, so this factor is now hardly worth considering.
And a quick one for the graphic solution… ensure to write an inline style for your graphics. Ensure it’s legible against the page or table cell background!! Make it bold and make it informative. Apple’s above in this article is a good example. You can’t read that alt text at all. It should be white, bold and maybe 12px in size so as to get the jist across as to what it’s all about to those whom are less educated as to the company and / or product promoted.
Excellent article !
Do you have any ideas or best practice when you whant a multi-part HTML and plain text mail ?
[…] David Greiner has written an interesting article on HTML email for Vitamin. […]
Email is a plain text application.
HTML-marked up stuff is merely an attachment. If there is no plain text, then it’s a blank email, and it looks like spam or a clueless sender. It’s appalling how many businesses send “important” information without the courtesy of sending it in plain text, and even worse is the general lack of clues when called on it.
HTML is *not* email. Let me be clear. An email body is plain text. Nothing more. Anything else is an attachment and is subject to loss without notice.
an no it
[…] Vitamin Features » HTML Emails - Taming the Beast (tags: html Email reference) […]
In an informal survey of my clients, family and friends, here’s what I discovered about HTML email vs text only email:
those who did not work with code had zero resistance to html email
those who did work with code hated it
The divide was rock solid. Perhaps it’s something to keep in mind…
Haha, this is good. My client has kept bugging for over a month to show them how to send HTML emails.
Actually, my client doesn’t even know what HTML is, but HTML email is the whole idea.
I had a client that actually wanted me to send out an attached jpg of the email b/c they didnt want to deal the “images turned off” crowd. I gently explained that was not the solution.
Great article. I think beside the “Must Haves” and “Should Haves” we need to have the “Check List”. One thing I thought it’s extremely important if you design the HTML Email in-house (non 3rd party) is make sure the images are in ABSOLUTE URL. I made this mistake once in my early days. Here’s a sample of my “Check List”:
1. Search all and make sure they are absolute path
2. Spell check
3. Always have someone else to proof read before you send it out
Interesting vibe I’m getting from comments… So the added visual appeal, level of interactivity, and positive psychological and emotional response of the evolving web has no place in e-mail? A company is to spend ridiculous numbers of dollars on visual marketing plans, try to spread that identity across printed materials, a website, an office, and whatever, only to break the continuity because some cranky programmers are getting uppity about pictures in their inbox?
Sure, a lot of HTML based e-mail messages we receive are an affront to the senses. But hey, so are a number of web sites. Doesn’t mean we all go back to using Gopher or something similar to avoid ugly pages.
HTML in e-mail is yet another avenue for savvy (not to mention forward-thinking) designers to flex their creative muscle. It’s another challenge for those unafraid to take it on. Which, in my estimation, should be everybody. Traditionalists in this industry get steamrolled.
I thought this was a stellar article and indispensable reference for anyone responsible for anyone composing and distributing e-mails on a large scale. The reference table of mail clients and examples of graceful degradation alone make it bookmark-worthy.
I have only recently started doing HTML emails and so from small amount of information I read, I made it my stance to always use “old school” HTML with tables, spacers and font tags. I did one just this week: http://messagesender.kmp.co.uk/TemplatePreview.aspx?templateId=124
Nice article, some very useful bits of information.
The Perl module MIME::Lite is a great way to generate multipart/alternative messages so you can have the best of both worlds by including HTML and text. Most clients can handle negotiating whether to use the text or HTML version.
It also allows you to embed the images in the message which gets around the problem of mail clients not displaying external images.
nice to know.
Pity i’m not at a stage to start sending newsletters yet.
:(
Great article! I was just talking about Newsletters.
@common sense
First of all, there is no such thing as a ‘CSS Table’. What was referred to in the article was the use of run-of-the-mill tables with CSS styling.
Second, I find it hard to believe that the _text_ used for CSS is going to hog bandwidth more than a pile of spacer gifs and 5x nested tables.
Third, that link you provided is rubbish. Obviously, the author lacks the intelligence to create a standards based Web page, fears for his livelihood and seems to also be brainwashed by M$. That tired outdated propaganda made my stomach turn. For God’s sake man, of course M$ is gonna make websites that work best in IE - cause it’s chock full of proprietary code and Active-X B.S.
Come out of the dark.
@Peter - “I configure every email client that I install for my customers to quietly ignore HTML email”
I am certainly glad I am not one of your customers.
Shameless plug for our Free Newsletter Templates website: http://newsletter-templates.kekeko.com. We use tables with inline styles.
[…] Take a look inside David’s brain: HTML Emails Recommendations […]
Great article! I’ve not had much luck finding useful information on designing and sending html email. I think there should be more articles on this subject because it’s painfully difficult to find good info on it out there.
Ok, so I know from this article to use tables and css and images with alt atts and stick in an unsubscribe link and all that, but how do I get the HTML into an email and send it?
[…] Vitamin Features » HTML Emails - Taming the Beast Great tips for what (not) to do when sending HTML e-mails. […]
[…] Het wil niet altijd even makkelijk zijn om een mail template te maken die degelijk kin elkaar zit en ook nog eens in alle verschillende situaties correct word getoond. Hier een stel artikelen en interessante linkjes over het hoe en wat in detail voor het maken van degelijke mail templates. Zo hebben ze bij Camaign Monitor (een online mailinglist service) hele fijne tips, een stencil waarin je mooi kan opzoeken wat waar wel en niet werkt. Maar ook bij Vitamin hebben ze er het nodige over geschreven Last but not least is er dan nog MailChimp. Zij hebben een hele mooie Email Design Guide en een compleet artikel over email marketing etiquette online staan. Om het dan nog even helemaal compleet te maken ook nog even een linkje naar de CAN-SPAM ACT, dat is zegmaar de regelgeving aangaande email marketing. Altijd handig om te weten. […]
I would do a text-only version and a link to a pdf version (with offers or info, etc)
[…] (The quote above is taken from Vitamin’s HTML Emails: Taming the Beast feature written by David Greiner, co-founder of Campaign Monitor, an email marketing tool. Please note I’m not at all picking on Campaign Monitor or Vitamin — both are excellent resources. This example is one of millions.) […]
[…] Vitamin Features » HTML Emails - Taming the Beast (tags: html webdesign formatting) […]
You mentioned Mark Wyner’s image replacement technique and showed an amazing example…where can we learn more about this technique?
@Diane
Try iPost.com. Basically, you make an HTML doc for the email, and a text ver. Always do a text ver., and then upload it to these guys. They send it out to the list of emails you upload to them. They manage opt-outs etc.
They check the emails for probllems related to SPAM - a real person looks at them, not just a software ’scan’ - and they’re cheap.
There are apps (for Mac anyway) that can send HTML emails but why bother yourself with all the related SPAM baggage.
No, I don’t work for them. We use them for our company and our clients.
Hey all, thanks so much for the kind words and useful advice being thrown around.
@R Flowers and @George, I agree that this is only the tip of the iceberg when it comes to getting the best results from email. Avoiding spam filters, staying off blacklists, correct multi-part formatting and other deliverability issues all deserve their own articles.
@Mark Crocker and @Graham, Mark Wyner’s awesome write-up on the best approach to using CSS in your email so it degrades gracefully is a great one to check out on that front. He’s even provided a free template you can download and tweak yourself. As I mentioned in the article, I’ve also tested CSS support across all popular email environments before which is a good reference on what you can and can’t get away with.
@Sean - Amen! I couldn’t have said it better myself.
David and several other people have mentioned including text-only as an alternative using multipart messages. You might be surprised by some of the information here: http://www.clickz.com/experts/archives/em_mkt/infra/article.php/1559901
I have done my own research to confirm this article, and was unable to find an option in any commonly-used email client or webmail site that allows you to even view the text part of a multipart message rather than the HTML part. Even the text-based client Pine shows the HTML version (without images or formatting).
No doubt someone will be able to give a counterexample, but in general, it seems that multipart is a waste of time and bandwidth. The strategy I have used instead is to allow the user to decide which format they want when opting in.
Adam,
Mozilla Thunderbird would be the most popular email client that comes to mind that offers full multi-part support.
Another great feature about multi-part that most people don’t notice is how web-based ISP’s use them. For example, Hotmail will display the HTML version of your message, but when you forward the email it will actually default to the text-version of the campaign instead of garbling the original HTML message.
Further to this, having text content that closely matches your HTML content may reduce the chances of your campaign being filtered as spam. You can check out SpamAssassin’s scoring criteria for more on this - specifically the MIME_HTML_ONLY, MIME_HTML_MOSTLY and MPART_ALT_DIFF tests.
Having said that, I do agree that offering your recipients the choice of text or HTML is a great approach. At the same time, I’d still recommend sending in multi-part to your HTML only recipients for the reasons mentioned above.
I always thought it was just the preference a user set for viewing (reading) messages. It’s worded in various ways depending on the client. “Allow images to display in messages” or whatever. Is this notthe case?
Interesting article - I’m trying tolearn more about the best way to design and sned these. With this in mind, I’ve a question about the sending of HTML emails.
We’re currently using a wizard to design and send our HTML alerts and its crap. Having now acquired CS2 I’ll be getting to grips with GoLive and plan to design the alerts as stand alones and import them for sending.
However I’d be interested to know how others send their alerts? Is a thirdparty broadcast tool the most common way forward or do we have other options?
I’d be grateful for input from those who do this a lot. Thanks,
David, well I stand partially corrected. Actually, I use Thunderbird and hadn’t known it had that functionality, thanks for that information. However, according to the statistics I’ve seen, it doesn’t have a significant user base; I only tested the clients/sites making up the top 95% of our users.
That said, the other reasons you mentioned might be compelling enough to make multipart a good idea.
Tom L, the “Allow images to display in messages” option still displays the HTML, but with a box in place of each image. It’s not actually showing the text part of the multipart message.
[…] Vitamin Features » HTML Emails - Taming the Beast […]
DIVs & CSS Positioning with Float & absolute widths
I’ve spent the past six months working on this same problem, and have found I can use DIV’s and SPAN’s with inline styles for every major, modern email client except Lotus Notes: Gmail, Hotmail, Yahoo, Aol9, Aol Web, Earthlink, Mail.com, Outlook 2000, Outlook 2003, and Outlook Express.
The trick is to create the outer DIV box with an absolute pixel width, and all inner DIV’s must use absolute pixel widths as well. All inner DIV widths must be correctly calculated as [containing DIV width] - [containing div padding] - [inner div margin] - [one or two pixels for IE’s broken box model].
Rudimentary positioning (good enough replacement for tables) can be achieved using the FLOAT attribute. For example, if you want two DIV boxes side-by-side, use the formula above to find the available totabl width you have to work with. Say your containing DIV is 500px, with 5px padding. 5px right-padding + 5px left-padding is 10px total; 500px - 10px = 490px; 490px - 2px (IE) = 488px. Set your left DIV width = 244px, float=left, and your right DIV width=244px, float=left. Your DIV’s will float beside each other on the same line, in all email clients listed above.
Just remember, DIV’s & SPAN’s, absolute pixel widths for all boxes, no exceptions, calculate all inner box widths correctly, and use the FLOAT attribute for positioning.
“Just remember, DIV’s & SPAN’s, absolute pixel widths for all boxes, no exceptions, calculate all inner box widths correctly, and use the FLOAT attribute for positioning.”
Oh yeah, and use inline styles only, no linked styles, no embedded styles with the style tag. Also, no javascript, it gets stripped.
I converted a tables & inline-styles based email to a pure div/span/inline styles email, and shrunk it from 86KB to 22KB. If you’re sending lots of emails as I was, making the conversion is definitely worth it.
[…] HTML Emails – Taming the Beast (tags: email css formatting) CSS, Email « Firefox-Erweiterung: Googlepedia links for 2006-06-10 » Tags / Verwandte Artikel: […]
[…] 更多参见原文：HTML Emails - Taming the Beast […]
Thanks Mr. Greiner for the very helpful advice.
[…] HTML Emails - Taming the Beast […]
Hello,
I’ve tested with both CSS and Tables for the layout and in the end I choosed tables. My newsletter goes to clients using: Outlook, Yahoo, Gmail, Thunderbird, etc.
The only newsletter that looked the same in all was the one using tables.
Gmail was the one who made me decide on tables, because it supports background images only if you set them in a TD.
Hello,
I’m in the newsletter bussiness, and this article reflects all steps to consider when designing a newsletter.
Very well done!
Regards, Rafa
Thanks for spreading the good word on HTML emails, David. Your article turned out great and it’s nice to see so much action in the discussion.
Long said that his client doesn’t really understand the concept of HTML email since s/he doesn’t know what HTML is. That’s a really excellent point. Many clients see “pretty” emails in their inbox and want colors/photos in their own. But many don’t understand the technical difference between plain-text and HTML, which is why we must be conscious of how we explain it to them.
As for Peter Newpiper. May I suggest some chamomile tea? HTML emails aren’t nearly as satanic as you’ve painted them. And I must agree with Oli’s point that forcing your HTML-email preferences onto your clients without their knowledge is not only childish, but also self-serving and pathetic. Your clients should be treated with respect. That’s how I treat my clients. Let them decide as adults how they wish to have their email clients configured.
This post should be taugh at school.
http://collaborativemarketing.blogspot.com/
I do quite a lot of HTML emails at work. My experience thus far has been that CSS is barely worth even attempting, as Hotmail and Gmail seemed to strip (all / most of ) it out.
So every time I did a background:url(…) I had to do a background=”…” as well; every a style=”…” had to be backed up with a nested font color=”…”. I figured, well, if I’m playing safe and backing up every css thing with an old school equivalent, why even bother with css at all. So I’ve only really used it for a few pure tweaks that make things slightly nicer but nothing too important at all.
I must admit I didn’t know about the style-element-in-the-body thing for Hotmail - that’s very helpful - except that if Gmail still strips the style element altogether, it’s really not as helpful as I thought.
I guess for the time being it’s sticking with a very occasional bit of inline css for little “cherry on top” stuff (like text-decoration:none or something) but fundamentally… back to the bad old days whenever it’s email time.
Still, nice article, thanks.
[…] Vitamin Features » HTML Emails - Taming the Beast Very useful article on some of the basic ins and outs of HTML emails (tags: html emails css table inline) […]
That is a pretty good design.
[…] Website besuchen Gefunden auf pixelgraphix […]
It’s really Cool!
The plain text alternative should have really been listed in the ‘*must* have’ list, not the end of the ’should have’ list. In fact, if you can talk the client out of wasting their time with useless HTML mail, then that’s even better.
But another thing that organistions should do is to ask the user which format they prefer, with the option defaulting to either plain text or multipart. If they explicitly choose plain text, don’t send the HTML version in the e-mail at all. The plain text e-mail can, and probably should, still have a link to the HTML version online. If they ignorantly choose HTML, then send the multipart version anyway.
One more thing the article forgot to mention. When developing the e-mail, it unfortunately requires a DOCTYPE that triggers quirks mode. I found out the hard way that Thunderbird won’t render in standards mode at all and I’d expect all web-based mail clients to be sending quirks-mode triggering rubbish to their users as well.
[…] In HTML emails: taming the beast David Greiner says some very useful things about HTML email design. […]
[…] Vitamin Features » HTML Emails - Taming the Beast […]
Link campaigning
http://warpspire.com/journal/web-production/testing-html-emailers/
[…] Taming the Beast Filed under: Reading, Resources […]
[…] more | digg story PermalinkTrackBack […]
From the “The Should-Haves”
5. A text-only version of your email. Some of your recipients may set their email client to only show the text version of each email, so make sure send your email in multi-part format, which includes both the HTML and text-only version in a single email.
How do you send to emails in one email? I have not seen this before?
@Chris, you can specify different content-types in your emails as well as what character set to use. You do this by adding a small detail to your mail headers and than some declarations in your email content.
Here’s a good rundown on the specific formatting to use. Also, there are loads of email components out there that make light work of correctly formatting your emails, such as the PHPMailer Email Class.
Thanks for this article, it’s perfect for me ;)
Keep up the good work, and thanks for introducing me to thinkvitamin, now i’m off to see what else I can learn :)
[…] David Greiner of Campaign Monitor has written an interesting article on how to design html newsletters and be sure your customers will read them correctly. […]
[…] La réponse d’un professionnel de la profession, David Greiner de Campaign Monitor, est : no problemo. Ma réponse est : ça dépend. En se renseignant sur la meilleure façon de designer une newsletter, on découvrira vite qu’ il est aujourd’hui possible d’utiliser les css de manière intensive dans un emailing, si on admet que la meilleure approche est celle du “Degrade with Grace”[1], approche longuement et brillamment expliquée par le même David Greiner sur Think Vitamin ou Campaign Monitor, ou A list apart (il écrit partout ce monsieur, et plutôt bien). […]
[…] HTML emails […]
At Plum we design and code emails sent to several million people a month, for web applications, newsletters and opt-in email marketing. We track metrics in many of these, including image-loading and click rates.
In almost every market, including the IT sector, visual emails generate a better response rate - often 200-300% better. This is true even if the message is heavily image led.
In a regular marketing email from a trusted brand, such as a major retail store, 25-40% of recipients will download and view images even if there is little or no text content.
We have found that a combination of strong headline text and image together deliver the best results. Additionally, people are more likely to buy products they can see in the email, and are more likely to forward visual emails to friends.
Informative newsletters, such as weekly updates on financial markets, are a little different, but still perform better when delivered as HTML with a little design and branding, plus tables, charts and graphs. This provides identity, and encourages trust among recipients, as well as communicating information more clearly that plain text alone can achieve.
I’m curious as to why some people seem to think that (HTML email == spam). As far as I’m aware, the definition of spam is unsolicited email. I subscribe to a number of email newsletters, most of which are sent as HTML, and I find them to be very interesting and informative, and not in the least bit spammy (especially considering I have asked to be sent them).
Yes, a lot of spam emails are formatted as HTML, but taking that one step further and claiming that all HTML emails must therefore be spam is on a level with saying that everyone who eats rice must be Chinese.
[…] I’ve just been reading David Greiner’s HTML Emails - Taming the Beast article on the Vitamin website. Its a great article and makes some good points, especially for those who are just about to torture themselves for the first time by creating a html email campaign! […]
Great Article! You can always test your email blast in a LYNX Text Browser before sending it out. This will show you what any text-based reader would display.
Great article, but could you add some words on the pros and cons of sending the images attached to the mail?