So I just read (thanks to a link from Jason’s del.icio.us feed) an interesting reversal of position on Jeffrey Zeldman’s blog on the subject of HTML e-mail. It references the Email Standards Project.
It’s an interesting approach, and probably the best way to handle the issue, but I still would recommend avoiding it at all costs, if it’s at all up to you.
The reason (primarily) is that at this time most e-mail clients are still very lacking in “real” support for standards-compliant HTML and CSS. If you stick within the limited scope of the common ground, it’s OK, I guess, but the problem inevitably becomes maintaining that stand, once you’ve agreed to do HTML main in the first place.
This stems from the fact that it’s usually the marketing geniuses who insist on the fancy presentation that requires HTML in the first place. The problem is that once you’re doing HTML at all, they know that you can make it look more like they want it to look, and they don’t care that you would need to resort to all kinds of non-standards-compliant table-based hackery in order to achieve that look consistently, due to the lack of consistent support in the various clients.
Yes, this is the slippery slope argument, and I guess you could just as easily argue that the only realistic way to tackle this problem is to work towards compliance in the major e-mail clients and embrace the ones that do offer it.
I just can’t help but not like the idea of HTML e-mail in the first place. We already have a perfectly good delivery platform for HTML: it’s called a web page. Last time I checked, almost all e-mail clients will convert a plain-text URL into a click-able link, so I say keep the e-mails themselves plain text, short and sweet, with a link to a web page for the full HTML content of what you’re trying to present.