Email html design and deployment quick tips

I create a lot of emails campaigns on a regular basis. Creating emails that work in all the mail clients can be a daunting task, if not sometimes impossible. Unlike web pages, you have many more combinations of email clients and browsers that may view your email. Add the fact that many email clients are blocking images, stripping CSS, or just outright ignoring all the great web standards we have worked towards for years, and you have a real mess.

There are some simple rules you can follow which should make life a lot easier. Testing of course is still required and many strange anomalies will pop up. Web based clients change without warning, so constant testing before every email deployment is a must. Below is a quick list of things to watch out for.

• Use tables, tables are your friend when it comes to email deployment.
• Use spacer gifs, yes you heard me right, spacer gifs are far more reliable in the world of email clients. Also check out my entry “Outlook 2007 – When is 200 pixels not 200 pixels? Spacer gifs“.
• Use inline styles on your links and put all text styles inline in your <td> tags.
• Don’t use UTF-8 encoding; you will get gibberish in some mail clients, use HTML entities when possible and Western European encoding, aka charset=iso-8859-1.
• Try to avoid using images for text, especially titles or body copy as most clients are blocking images. This rule could vary depending on your target demographic. People are probably more likely to turn on images for a game newsletter or tech savvy newsletter.
• Have an online version available linked at the top of the email. e.g. “Trouble viewing this email? Try our online version”.
• Avoid fancy CSS like position and float; stick to basic style attributes like font and padding, even margin will be removed sometimes.
• Build white space margins into your images and use HTML align=”right” to align, not float.
• Use background images sparingly, some clients remove them.
• Try not to rely on doctypes, in fact I remove them so I can see how my emails will look without them, although you may find cases where you need them with earlier versions of Outlook.

This list sounds pretty horrible and restricting if you are a standards compliant HTML coder like myself. You probably feel like you have just been kicked in the face and stepped into a time machine and the year is now 1996. This is the way the email world is. Just when you think one client is fixed something else comes along and destroys all hope. Hotmail was the worst client to support for a long time, but their new live mail isn’t half bad at rendering emails. Just as hotmail was fixed a new abomination arrived called Outlook 2007 which uses word to render all emails. You may want to check out my earlier entry titled “Outlook 2007 – When is 200 pixels not 200 pixels? Spacer gifs“.

If you are new to email coding expect a lot of growing pains. Remember that redundancy is the key. For example, if you use a style like img { border:none; }, add an inline style=”border:none”, or even better yet use border=”0″. You may find issues with even simple HTML elements like <div> tags not working the way you expect. The culprit will most often be Outlook 2007, but these issues can crop up anywhere. Microsoft themselves doesn’t want to support Outlook 2007. Their official Xbox newsletters have a line at the top that says “Read this issue online if you can’t see the images or are using Outlook 2007.” That said you can usually get emails to look perfect in Outlook clients if you take the time and effort. There is however clients like Lotus Notes where you may have to sacrifice your design to the whims of client renderer.

The only real saving grace is that email is usually a fairly static medium, so you are not going to have to go around and update 500 pages and styles. If you do have dynamic email campaigns I recommend building and branding them dynamically with a server side language like php and then outputting the static files before sending them off to your deployment platform. Some platforms will also support dynamics builds. At the end of the day, if you stick to HTML principals that worked in 1996 and mix in a bit of basic CSS you are probably going to be okay. Happy coding and please never use these tips for regular web pages.