However, when delving into the world of email, you are required to adhere to standards much stricter than those outlined by the browser's rendering engine. Any HTML that goes into an email is run through a preprocessor which will strip out anything it feels will compromise security, privacy or normal email behavior. Once the HTML has been through the preprocessor it is handed over to the email client's rendering engine. This engine could be roughly the same as a browser's rendering engine (like Apple Mail using Webkit) or it could be something... different (like Outlook using Microsoft Word).
Since there isn't exactly a set standard as to what does and does not get stripped out of an email during these steps, HTML emails are prone to some interesting compatibility errors. In my experience, though, I've found that following the seven steps should get you out of most tight spaces when designing HTML emails.
1. Use Tables For Everything!
Are you cringing? Good. In modern web development, using tables to display anything other than tabular data is frowned upon for a litany of reasons. However, when it comes to email clients, some still do not recognize the validity of div based layouts. Because of this, table based layouts are the only ones that are rendered correctly across the board. In email HTML, tables aren't just for the odd layout hack. Tables are life.
2. Keep Your Styles Inline
Cringing harder? Sorry. As mentioned above, many email clients will strip out anything that they think will compromise email quality. For many browser-based clients this includes all external scripts and styles, so there is no way to link your style sheet to your HTML email. This leaves you with two options: embedded CSS and inline styles. Well not quite. Gmail doesn't like to play around when it comes to extraneous HTML tags. All head, body and style tags are stripped out when Gmail renders HTML. Get that copy/paste hand ready, your best bet is going to be inline styles.
3. Define Backup Fonts
There's nothing like a good web font to bring your site's copy to life. Of course, it’s only natural that you'd like to bring that same liveliness to any email templates associated with your site. Unfortunately this may be more difficult than it seems.
Some clients, like Apple Mail, allow the linking of web fonts in the head of an email. However, as mentioned in the previous tip, some browser-based clients, like Gmail, strip out any head tags. This means that, in many cases, web fonts are out of the question and Sans Serif web safe fonts are in.
Of course, you’re still welcome to link any web fonts you’d like and apply them to various elements of the page. Just make sure that you include at least one web safe backup font in the font-style definition.
Oh, and one more thing. Outlook is going to ignore those backup fonts you’ve so diligently included in your inline styles. Because of this, make sure you also include an Outlook specific conditional style defining all backup fonts you’ve chosen.
4. The Images May Not Load. Design Accordingly
Simple, but important. Many email clients include privacy options that allow for the user to specify whether or not they would like to download email images by default. If you haven’t taken this into account, your email may look very different than you intend. When building your template make sure you specify any heights, widths, margins, etc. in such a way that things look ok even when your images have disappeared.
5. Use a Third-Party Tool to Test Your Emails
Another simple, but important tip. I cannot emphasize just how valuable a cross-client testing tool is to email template development. Realistically, there is no way to manually test your custom email across all relevant email clients. It’s either going to eat up too much time and too many resources, or your testing is going to be woefully incomplete. Luckily, there are some incredibly helpful tools designed with cross client email testing in mind.
Personally, I’m a fan of Email on Acid. It’s powerful and super easy to use (plus it’s got a cool name). However, there are plenty of other tools out there like those from Litmus, Campaign Monitor, and MailChimp that are more than capable of getting the job done. Fair warning, none of these options are free, but depending on your timeline a free trial might cover you. If it doesn’t, don’t balk at the price tag. These testing suites are worth every penny.
6. Know the Limitations of Your Editor
If you have full control of a mail server and custom email code, you’re probably in the clear when it comes to editor related issues. This pertains more to those using a third-party system where it’s required to enter any email HTML through an online editor.
If you are using an online editor, take fifteen minutes or so to play around with it. For various reasons, some editors will strip out or modify parts of your custom HTML. We had an issue a while back where an online editor would strip out all conditional styles and comments. This meant our little Outlook font work around (see #3) was no longer possible and we had to settle for a less appealing font. Understandably, the client was less than thrilled.
Try your best to find any editor-related gotchas at the beginning of your project so they don’t become a surprise frustration later on.
7. Be Prepared to Make Compromises
Creating HTML email templates is a tricky task. There are far too many email clients to achieve a perfectly compatible, all encompassing, cross-client template in a reasonable amount of time. Because of this, there is a choice to be made: Do I want to keep 100% of my design and functionality or do I want to try to give the widest possible audience a less-than-perfect version of my design and functionality?
Unless your email template is relatively simple, compromises will have to be made.
If you stick to these guidelines and exercise patience, you just might come out of HTML email development with all your hair intact! Have any other tips? Feel free to add them in the comments below.