A couple of days ago, we sent out the August CMP newsletter. You can see a copy of it here. If you've been subscribing to our mailing list for a while, you'll have noticed that we made the switch from plain text to HTML.

So why the switch to HTML?

Essentially, if you follow some basic guidelines, I think the usefulness of the markup outweighs any of the negative points. I think the end result is easier to read, cleaner and more functional. For a quick comparison before I break the guidelines down, look at this: HTML Version | Text Version

In summary: using HTML in a newsletter should increase readability and functionality.

CMP Guidelines for HTML Newsletters:

• No images


• No link shrink


• Simple markup


• Follow standards


• Use CSS

Why no images?

Well, one of the nicest things about email is its ability to be indexed. Email is wonderful for parsing, cataloging, searching, etc. If you replace what would have been plain text with images, you remove that function.

If you must have images, then there are at the very least two rules to be followed: 1) don't use them to replace what could be text, and 2) don't imbed them in the newsletter. Keep them on a server and reference them as you would images on a normal webpage ([img src="http://image.jpg"]).

Why not imbed images? Because it's poor etiquette — it slows down servers, slows down mail clients and fattens inboxes. Keeping the images on servers means that the burden of the image is placed on the server and not the client. It also means that if the image is removed from the server, it can no longer appear in the newsletter. But even so, as long as critical text is still provided as plain text, then the meaning of the newsletter is retained.

Link shrink
Services like Tiny URL are ostensibly nice when you're sending URLs in plain text (and thereby aren't able to mark them up into links) but, to be honest, I've always felt them to be sneaky. I like to know what I'm clicking on, and I have a feeling a lot of other people out there do too. Since we're using HTML now, there' s no reason to shrink links into small URLs. Keep the original URLs so that even the most paranoid of recipients can, at the very least, right click-copy, and paste the URL into their browser to make sure it's a spam-free link.

As far as simple markup, standards and CSS, this is all to ensure that the newsletter appears as intended on the host machines. Indeed when marking up a newsletter, we should be formatting with a clear purpose in mind: readability and functionality.

One note on the CSS: make sure you use inline CSS. Don't link to an external stylesheet or include styles in the header — this won't work on all mail services. Of my limited testing between Apple's Mail, gmail and another generic web-based mail reader, the only version of the newsletter which looked identical on all three was the inline CSS one. Unfortunately this clutters the markup. But since these newsletters are fairly simple to begin with, I think the universal compatibility is well worth the slight messiness behind the scenes. (View the source on the HTML version to see what I'm talking about.)

Let the newsletter structure dictate the markup. For the CMP newsletter, we broke it down into five sections. From top to bottom: The main headers, contents, body, unsubscribe instructions and links to our projects. Chances are, we'll never need more than this. If you return to the comparison link above, I think you'll find that the non-obtrusive integration of the links into the body of the HTML version is far more functional than embedding links alongside text in parentheses.

So if you're sending HTML newsletters already, maybe it's time to double check and make sure you're keeping it clean, functional and to the point. And if you're doing it hardcode ASCII style, maybe it's time to reconsider HTML.