Email Marketing Voodoo - MindComet

Dec07

html, coding, best practices

My Best Practices: Coding

Here are a few methods and rules I abide by every time I code an email. Some of them are a bit lengthier than others, but all are useful to me when it comes to coding emails.

Much like web browsers and web sites, mail clients and emails are VERY specific with how they interpret and display code. Your code must abide by certain rules. We are at the email clients’ mercy.

Tools:
Emails are constrained to utilizing HTML, not CSS to layout their designs. Try to avoid using Dreamweaver or any other code generating app. Doing this will certainly cause your email to break in numerous email clients once you start testing (DW adds gratuitous code). If you don’t know already, learn simple HTML and learn how to code “by hand”. Use a simple text-editor such as TextMate.

Structure:
As a rule of thumb, always declare a specific width for every table and table cell. By not doing this, it will cause your message to display in a wacky fashion with specific email clients (shame on you, Outlook ‘07).

You don’t have to always include a height attribute for each row, but it doesn’t hurt. Also, make sure all cells in your row add up to the total width of your table.

Instead of utilizing colspan and rowspan, embed tables within tables… this will allow for a more flexible coding structure. It will also be easier to maintain with potential changes to your design, as well. If you feel like you will lose track of where you are with your code, use comments to tag different section of your email.

See the screenshot below for collapsed code from an email I coded:

Images:
Every image should have a few things:
a) its own table cell (in most cases)
b) width and height attributes declared
c) supporting alt text which describes the image or any text that may be embedded within it.

Backgrounds:
If you have to use a background image for your table or table cell, also declare a similar background color that matches the image as closely as possible. This is a good habit to get into since Outlook ‘07 doesn’t display background images. With a background color similar to your image in place, it appears less-broken in Outlook ‘07.

Text Styling:
Every link and block of text should have all of its attributes declared in-line.
With CSS, you can state your text / link styles in the header and have it applied to all IDs and classes below, but since we’re dealing with email we have to specify the style within the body of the email. To do this, wrap a span tag around a regular block of text. Like so:

The same applies for links, with an anchor tag instead of a span tag.

If you do all of these things from the get-go, testing will go so much more smoothly. I guarantee it.

Posted by Bryan Quilty on Dec. 07, 2009

Comments

Gravatar

Good article, Bryan!

I have found that for some email clients, such as Gmail, we need to split the text style declarations as you’ve indicated above. Some people may try using this shorthand style=“font: regular 12px/20px Arial, sans-serif; color:#000” but it may produce unexpected or inconsistent results.

Posted by Boris Mahovac on 12/07/2009 02:41 PM

Gravatar

Boris,

Yes, in my experience, shorthand is always problematic in a number of email clients (the exact ones escape me right now, but I believe Gmail is one of them). I always use longhand for consistency across the board.

Posted by Bryan Quilty on 12/07/2009 03:32 PM

Notify me of follow-up comments?