Search Marketing: Optimize your HTML Newsletters for Maximum Compatibility
Any decent search marketing campaign will, at some point, have to entertain the effectiveness of promoting e-newsletters. The real bottom line is that marketing your site’s content by way of e-mail promotions can only serve to drive prospective visitors to your site (if not for the simple fact that providing less opportunites for potential visitors means, well, less potential visitors).
E-mail clients are way more finicky and moody than web browsers, so, the real question–for the purposes of this post, at least–is how market your e-newsletters to largest possible audience.
Here are six simple tips on how to best optimize how your HTML newsletters are coded to reach the widest possible audience:
- Don’t be so fancy–code in HTML 3.2
- Do I have to download another file–again?!
- Gain control–lose your HEAD
- Use inline styles
- Duplicate your styles when using anchors
- Use CSS 1–sparingly
HTML has made some great advances since its inception. The HTML 5 spec includes the canvas element, which essentially gives you the ability to graph points and draw vector lines on-the-fly. I mean, how freaking cool is that?!
Newsletter technology, however, is not so freaking cool. Most e-mail clients tend to strip out HTML elements, and/or refactor your code, destroying most modern layouts based on silly things like “standards,” and “compliance.”
The solution? Code your newsletter under the HTML 3.2 specification. This basically means using TABLEs to control page layout and minimal CSS1 to define styles. In other words: technology circa 1998. (There’s nothing quite like living in the past.)
To help combat spam, most e-mail clients these days will ask if you want to load images, or download any supporting files. (One way for spammers to tell if messages are actually opened is if an HTTP request is made to their servers for supporting files.)
What does this mean for the honest newsletter developer? Well, you should already be avoiding JavaScript files (like the black plague), but for simple styling, don’t link out to external files:
<link rel="stylesheet" type="text/css" media="all" href="http://server.com/newsletter.css" />
Define them in your document:
<head>
<style type="text/css" media="all">
p {
font:11px Georgia, serif;
}
</style>
</head>
3. Include nothing in the HEAD
Most developers are used to lumping external files and META data in the <head> of the document. This can have its advantages (or, disadvantages), but must simply be avoided when developing newsletters.
Why? Mail clients like to add their own e-mail headers, so–while some will keep your headers–most will either modify them, or strip them out entirely, so it’s better to simply think of anything contained in the <head> as not belonging to you.
So, instead of normally defining a style, like:
<head>
<style type="text/css" media="all">
p {
font:11px Georgia, serif;
}
</style>
</head>
Do so within the <body> of your document:
<body>
<style type="text/css" media="all">
p {
font:11px Georgia, serif;
}
</style>
Your <head> belongs to them.
While some most mail clients will read your stylesheets, many will simply not. So, it’s best if you simply ignore them; and, simply do not rely on CSS-based layouts. (Think of how your document would render with the stylesheet completely stripped out for a sense as to how your CSS-based newsletter will look on some e-mail clients.)
So, if you have to use CSS–as many of us do–do so inline. Instead of defining classes or elements:
<style type="text/css" media="all">
p {
font:11px Georgia, serif;
}
</style>
Define each element as you go:
<p style="font:11px Georgia, serif">
The result is more code, that works in more e-mail clients.
5. Duplicate your styles when using anchors
Some clients will strip out styles for anchors, or refuse to inherit the parent style, so–even if you’re explicitly defining how your anchors should look:
<a href="http://server.com" style="font:11px Georgia, serif">I am so enticing you>/a>
Define the parent container to look the same:
<td style="font:11px Georgia, serif">
<a href="http://server.com" style="font:11px Georgia, serif">I am so enticing you</a>
</td>
While some mail clients are CSS-friendly, many are not. For example, GMail and Outlook 2007 do not support CSS-based layouts, nor background images. (Many mail clients do support background images, just use them gracefully, such that there absence doesn’t take away from your message.)
Even though some mail clients will render the above examples as you would expect, others will not. Instead of explicitly declaring the font style, break that down into specific attributes:
<a href="http://server.com" style="font-size:11px; font-family:Georgia, serif">I am so enticing you>/a>
Your overall codebase will larger, and more bloated, but these guidelines will help grauntee your HTML newsletters will be optimized for maximum compatibility.
June 30th, 2008 at 4:08 pm
This is important information. This really helped me. Thank you.
However, the article is structured in a way that makes the content confusing. Usually in articles like “x number of tips” — each tip is valid on its own and the more tips the user could follow, the better.
In this article, tips 1, 4, and 6 are independent tips, each one can be implemented. Tip 5 is some extra detail about tip 4.
And here is the most confusing part: tips 3 and 2 are back-up recommendations of what to do if you can’t follow the advice in tip 4:
Now my question. Do you recommend putting in a DocType declaration?
Again, thanks so much. I hope you take my criticisms in the constructive nature in which I meant them.
June 30th, 2008 at 5:15 pm
Hi,
Thanks for your reply.
Perhaps this is simply a case of my dyslexia working backwards, but I meant to point out each step do illustrate newsletter “don’ts” that would otherwise be website “dos.” Each step does improve upon the step before, so–yes–the bottom line is: use inline styles
To answer your question—while most e-mail clients will ignore your
DOCTYPEdeclaration, outright, some (like Novell GroupWise) do keep them, and others (like Outlook 2003) are based on a web browser’s codebase (Internet Explorer), so: yes, it’s always better to declare it; and, especially if you have your e-newsletters archived on the web.(The real issue of
DOCTYPEdeclaration comes into play with web-based e-mail client, who need to maintain their own doctypes.)