The Curse of HTML Email

The Curse of HTML Email

Today I am researching HTML Email for a client newsletter. Out of the blue, I got another call from a friend asking about the very same thing. With the advent of Spring comes the blossoming of a thousand e-marketing initiatives!

Anyway, it seems like this should be straightforward cut-and-paste job, but there are several technical hurdles to overcome when creating a good-looking HTML Email. That’s because HTML email isn’t a simple self-contained document format like Word, nor is it a web page somewhere on a server. It’s a hybrid of both approaches, made difficult by wildly-varying HTML support in email clients. Remember when you had to code HTML for both Netscape and Internet Explorer in the 3.0 days? This is worse.

I’m still researching this, but there are four challenges:

  1. How to send HTML email in the first place. Sounds simple, but if you want iron-fisted control over the appearance of your email, you have to do some advanced digging. You can’t generally paste in raw HTML code into Outlook and hope it works for everyone. You could look for special mailer software designed for sending email blasts, either as a stand-alone client or something on the server side. Optionally, look into service like VerticalResponse. I have not used this service, but it does appear to handle the mailing side of things for you. You just paste in your custom HTML into a form, and it wraps things up nice for you.

  2. How to create HTML that works on all email clients. Email HTML support is spotty. You thought Netscape 4.0 issues were bad…each Email client is it’s own screwed up buggy browser. So you need to find common denominator HTML and test test test, if you care. Don’t forget web mail clients: the big ones like AOL (both the service, and the web-access portal), yahoo, gmail, msn. They often rewrite the HTML and strip out tags. Here’s some links on this subject: ReachCustomersOnline, CSS Email, [PublishingCentralhowto2, TemplateKit. The CSS Email link is particularly interesting in its discussion section, though there is a lot of whining from people who hate the whole idea of HTML email and have decided to take a stand against it. This resource list at florentinedesign.com looks pretty useful too…check out the article links.

  3. How to reference images in the HTML email. Where are they located? You can embed them into the Email themselves as a multipart-mime segment, but you have to make sure they actually work…what is the URI for a multipart-mime segment embedded image anyway? And does your email client actually allow you to do this?

    The preferred way, apparently, is to actually source the images from an external web server, and use absolute URIs in your HTML, but now you’re talking about maintaining a server with images on it.

  4. Testing all those email clients. If you are deploying a newsletter to a general audience, you had better test extensively to make sure it looks clean and professional as opposed to random and broken. By comparison, this is probably the bigger pain in the butt than creating the HTML Email itself.

1 Comment

  1. seuss 19 years ago

    is avoiding html email a viable solution?

    have yet to see a solution that warrants the time sink, $$$ outlay (if any), and unpredictability.

    the more i’ve looked into this, the more it’s struck me…“is this really a good idea?? WHY again is it worth it??”

    you might be better served with plain text which links to a web based newsletter.

    and this coming from a guy who likes pretty pictures and tightly rendered layout. i suppose i’ve learned to pick my battles.

    look forward to hearing what else you turn up.


    ——-