You can love email, you can hate email. An opinion can vary from one extreme to the other when asking any group of people, but almost everyone using the Internet spends part of their day sending, receiving, and reading email. One thing that the majority can agree on is having a dislike for HTML emails. Not only is the inclusion of HTML a red flag for most people (and software) that the message is spam, the email more often than not comes out looking like a billboard that got sent through a washing machine.
Why put together an HTML email at all?
Sometimes as a developer, you’re asked by clients to do things that normally wouldn’t cross your mind for one reason or another. HTML emails could fit into this category for many developers, but the fact of the matter is, it’s almost guaranteed you’ll be asked to put one together for a client at some point in your career. Clients will always love having the ability to send out a mass email that looks better than their competition, there’s no denying that, and there’s nothing wrong with it either. You can’t blame a client for wanting to get the most out of their Web company.
The difficulty for you, the developer, will come in with the design and development of the markup itself. Throughout the design you need to keep things simple. We’re well aware that email markup is a battlefield that no one is comfortable working on, You can still have a very effective HTML email design while keeping it simple and to the point.
Treat HTML emails as you treat webpages
Just because this particular document will be read in an email client does not mean that your development process should be any different than that of a webpage. It’s true that your technique will be modified to handle the new rules of your environment, but the fundamentals are the same. Always keep semantics and best practices in mind.
Are there any best practices for HTML emails? Sure there are, you’re dealing with HTML and CSS, and therefore all of the associated guidelines can be applied. The differences here require that you can assume images are disabled by each and every person reading the document. Many email clients will disable displaying images from external sources by default, which will include every image used for the design of your HTML email.
Tables are not the solution
It has been said many times that the true way to attack an HTML email is to get back into using a table for structuring the design. The standardista in me couldn’t disagree more. I don’t write this to offend anyone who stands behind the technique, but I can’t help feeling that it takes a step back. Using tables to structure the design of an HTML email disregards readers having to use alternative technologies to read their email. Semantic markup will be more beneficial than a table based layout.
In my personal opinion, if an HTML email is requiring the use of tables to achieve your desired effect, it’s time to revisit the design itself. Naturally from time to time, a client will demand a very specific design from you, and the only way to achieve it is using a table. Telling a client you can’t help them because the project inherits bad semantics can’t happen, you’ve got to pay the bills. The idea is to avoid their use until it’s absolutely necessary, and hopefully you’ll continue to be table-less in your development.
One of the most common reasons for using a table is to provide cross-client centering of elements in the design. Having the ability to center elements is very often a benefit to developers and a requirement of the design. Taking that away can severely limit an HTML email. Some popular clients don’t support centering via CSS with:
div#heading { width:500px; margin:0 auto; }Instead, style your document in such a way where you can control the left and right margins with a known value that will result in the centering of an element. For example:
div#heading { width:500px; margin:0 0 0 4px; }Using that style will often result in a centered element if you’ve styled your document in such a way where you know the width of your elements and their parents. Centering elements is now more work, but it helps as one technique to avoid having to resort to using a table.
Something else to keep in mind is that it is exponentially more difficult to deal with CSS support within HTML clients than it is for Web browsers. Web browsers will boast their support for CSS and standards-based markup. Email clients? Not so much. At the root level, they’re meant to send and receive email and get that job done. On top of that, superior organizing abilities among other additional features will help your email client stand out above the rest, but you don’t hear many people saying they use Thunderbird because it has great support for HTML and CSS email.
There has been a lot of literature on the ins and outs of HTML and CSS support using various email clients deemed most popular. One of the most extensive and comprehensive articles I’ve found is a piece posted to Campaign Monitor. Testing any HTML/CSS email can literally be an endless process, and knowing some pitfalls ahead of time can be beneficial to you.
Images are very important (to your design)
I’d like to emphasize that it should be a high priority decision to develop an HTML email around the idea that images are going to be disabled by default for the majority of readers. Both inline images and background images will be invisible to many people either permanently (due to email client settings) or until images are enabled by the reader on a per-message basis. It’s been said that first impressions are very important, and that people can tell whether or not they “like” something within seconds of seeing it. Keep that in mind when testing your HTML email. Don’t automatically enable external images, test with them disabled to be sure you’re making the best of your situation. That being said, it’s even more important for you to provide excellent alternate content for your readers, so should they decide not to enable images, your message is still conveyed.
Offer an alternate version for your HTML email
It is very important to offer alternate content for everything, HTML email included. There is a significant probability that a large percentage of readers who are going to receive an email will have the option to display HTML disabled; not only for personal preference by many, but it’s also a common security precaution put into place in corporate environments.
Something to keep in mind at the very least, is including a link to an online version of the message. Allowing a reader to view the document in a Web browser would be the least you could do. Better yet, offer a text-only version of the message for those readers who don’t accept HTML email. Many times, it’s stated that a text-only version is exactly that, and that it’s being displayed because you (the reader) have disabled HTML email. Including a message like that is unnecessary, because the root purpose of the email itself is to convey a message, not a design.
Further Reading
There have been many articles posted detailing actual testing of various techniques in multiple email clients, some of the better articles I’ve found are listed below:
How do you feel about HTML emails? Do you have any tips or tricks that have helped you in a pinch?
Comments
I always turn off HTML email support. Old time bad experience.
I admit, it would be great to receive nicely formatted emails, but not at the expense of exposing your computer.
and then..plain text is the good old thing 🙂
Jon: I thought I might let you know that your mailing list sent out an e-mail for your new entry today titled ‘A new entry titled ‘Making the Best of Video Using Flash’ with a link to last weeks entry.
Anyway, I’m not a fan of HTML e-mail at all. I’ve always kept it disabled when receiving AND sending mail. I remember a few years ago when Eudora was the IT e-mail client and a lot of people started using it because of it’s ability to use pretty pictures as an HTML background to your e-mail. It took a while for people to figure out that the pictures would only load on computers with Eudora installed and that everyone else got a bunch of jumbled text and broken HTML when they tried to view the messages.
One of the biggest problems with using CSS in html email is that many email clients (especially webmail clients) strip the head element, modify the body element, or otherwise make it difficult or impossible to properly style emails without resorting to inline styles. While I personally wouldn’t care as long as the email degraded gracefully, if your client (the one who’s paying you for your work) is getting the unstyled email it’s a problem. They’ll often demand that the design work for their emails because they get emails all the time that do. No amount of explaining will get some clients to budge on this one, and the unfortunate result is to resort to table-based layouts with inline styles.
I agree with many of the sentiments behind this article.
But, I’ve worked creating customer marketing emails for various large clients over the last few years and I’m sorry to say I still feel that it’s all but impossible to use CSS to any great extent.
The worst offenders for not supporting CSS are the webmail clients such as Hotmail (Livemail) and G-Mail and when we look at our clients data we often see that as many as 75% of customers are using webmail providers.
Currently when our clients require a grid-layout in an email to display products; going back to tables is the only answer (with of course a text only alternative (usualy sent in a mulit-part message)). I do hope the situation changes in the near future.
To get the ball rolling if somebody could point me at any references that could gave me some amunition for dissuading clients from sending marketing email based on table-layouts I’d be very happy to start evangelising CSS based emails (as I did with CSS based web pages quite a few years back).
I prefer receiving a well designed HTML email as opposed to basic text. I think HTML emails will become more common and email clients with support creating and receiving HTML emails, eventually.
I also end up using table based layouts with inline styles to make HTML emails work in the widest range of email clients.
The thing that has made my job the easiest for sending HTML email campaigns is using Campaign Monitor (as mentioned). Great tool and good resource for information.
I always use narrow widths to fit webmail space and inline css.
I also provide plain text alternative text, but I’m not sure about embedding images.
@Dan: You’re definitely not alone in your stance, which is exactly why the people behind HTML emails need to ensure that you see a message with the same value as someone who does prefer to read HTML email.
@Michael Chase: Absolutely… I also remember back to the days of Eudora. It’s funny how it usually takes the masses a bit of time tor realize that something is causing more trouble than good.
@Mark Reeder: You are absolutely right. If anybody thought supporting multiple Web browsers was too tough to handle, they shouldn’t be working with HTML email. Just about every client (Web based or otherwise) will treat an HTML/CSS email differently. You’re right, sometimes a project will come down to a tabular layout to please a client.
@Russel James Smith: You’re completely justified in saying that you can’t trust CSS to any extent in an HTML email. Keeping the design simple is essential to a successful campaign.
@Jared Cornwall: You may be correct in saying that HTML/CSS based emails could become more common and better supported over the coming years, but that is probably quite a way down the line unfortunately. We can always hope, though. Personally, I don’t have any experience with Campaign Monitor but the articles posted to the site are often well written and very comprehensive.
@Leonardo Ribeiro: Definitely, I’ve come across a few ‘guidelines’ for designing HTML emails in that you should keep widths to a number hovering around 560px and a few other tips and tricks. It’s always good practice to offer a plain text alternative.
CSS support among email clients is really poor and inconsistent. I am a huge standards proponent, but HTML emails are no place for positioning CSS. Now, that doesn’t mean you can’t still use semantic markup, but when it comes to layout, tables are still the best for the greatest compatibility.
A business email application still in widespread use is Lotus Notes, which will throw your carefully coded CSS all over the show. To achieve any sort of layout which will work across multiple email applications you have to use tables – it’s unfortunate, I know, but utterly unavoidable if you are going to allow Notes users to read your html emails. You also have to use old-style font tags in your markup for Notes – not good news.
@Justin Kistner: You’re absolutely right about CSS inconsistencies between clients. If a client is being completely specific about how they want their HTML email to look then sure, using tables for layout can become a necessity.
@Peter Scott: You bring up a great point, Lotus Notes is still used extensively, and as a few have said before, sometimes you just have to buckle down and use tables to get something right for a paying client. Unfortunately that will probably be how it is for some time to come as well.
I am a UI designer; I espouse the use of CSS and forward thinking markup; however, tables are not dead and are still a reliable construct for getting things done. CSS still has a way to go before tables are fully written off. Accept it.
@Gort: As far as HTML emails are concerned — maybe. There are times when it comes down to client orders having to be followed and CSS support just isn’t there as far as email clients are concerned. The decision by Microsoft to resort to Word rendering in Office 2007 for HTML emails goes to say that things are headed in an awful direction as it is. I can’t accept it when it comes to the Web, however. Thanks for taking the time to post your thought.
lease don’t encourage users to post HTML Email. It’s dangerous, takes up resources, and is not accessible. Even if it can be done correctly, it seldom is. Like putting metal in the microwave. It’s often better to say “don’t” than to teach people to do it properly.