I’ve reviewed the various objections to the use of HTML in email and, honestly, I think they are all fallacies. In many cases the objections seem to be more about the way HTML email is implemented in current mail clients than about HTML email itself.
The document here summarizes a number of common objections to HTML email. In this post I will offer a rebuttal to these objections. However, I should first point out that I might be attacking a straw man. Most of the anti-HTML email pages I’ve seen are relatively old. The issue appears to be generally less controversial now than in the past.
Here are the objections from the document referenced above, along with my comments.
1. HTML email is dangerous.
Here the objection is especially with regard to scripts but also with regard to other kinds of browser vulnerabilities (since HTML email is often rendered with the help of a browser plug-in of some kind). However HTML itself does not specify scripting other than to say that there exists a script element. A perfectly compliant HTML rendering engine could ignore all scripts. To me this seems like an obvious way to handle the issue. Plain HTML is passive and not especially dangerous.
2. HTML e-mail wastes bandwidth.
Certainly it is true that an HTML message will be larger, perhaps two or three times larger, than a plain text message. However most normal email messages are not very large. If I take a 2 Kbyte plain text message and bulk it up by a factor of five it is still only 10 Kbytes. In comparison consider the size of all the annoying ads and icons one typically downloads on the web pages one visits. Consider the amount of spam that circulates around the network. I suspect the bandwidth consumed by such junk is many times greater than anything likely to be consumed by legitimate HTML email. If one is concerned about clogging the network with crap, going after legitimate HTML email is not the answer.
3. HTML e-mail doesn’t always work.
Here the objection is that not all mail clients support HTML email. However, the lack of such support is becoming increasingly rare. Every modern client I’ve seen recently handles it. Even the text mode client pine displays HTML email in a reasonable way. In any case the multipart/alternative MIME type allows both plain text content and HTML content to be sent in the same message. This standard exists precisely to support mail clients that don’t understand HTML email while still allowing HTML email to be used with clients that do.
4. HTML e-mail can connect to the internet by itself.
Here the objection is to HTML messages with embedded images (for example) that use absolute URLs to access the image data. Again, this does not seem to be a problem for modern clients. For example, both Pegasus Mail and Thunderbird refuse to fetch images in such messages without explicit permission from the user. Again this objection is really about mail client implementations and has little to do with HTML email itself.
5. HTML e-mail renders slowly.
Here the objection seems to be about the added complexity HTML email imposes on mail clients. Certainly it is true that rendering any kind of rich text message is going to require more effort on the client side. So what? If one accepts that rich formats are useful (more on this below), then isn’t that complexity part of the application I want to execute?
6. HTML usually looks [horrible].
There is no doubt that some HTML email is really hideous. However, this is not a problem with HTML email itself. Instead it is a problem with the way people use it (or perhaps with what mail clients allow people to do with it). The solution is not to pull HTML email out of the hands of those who use it responsibly but rather to educate the people who don’t.
7. Digested lists hate HTML mail.
This sounds like a problem with the list digesting software to me. Why should a digest change the MIME type of the included messages? Perhaps the author of the digesting software thinks they are doing people a favor by converting the MIME types of all messages to text/plain. If so, that has little to do with HTML email. It is entirely related to an arbitrary design decision by the digesting software author.
Some people say that sending HTML email is pointless because the mark up adds nothing of significance to the content anyway. However, if that were really true then why do people use word processors when writing documents? Why aren’t all our documents in plain text? HTML adds a number of useful structural features like lists, tables, and embedded images to name three. Why not use them?
In fact, I’d like to go beyond what current mail clients seem capable of doing. I want to send potentially complex mathematical formula, together with associated line drawings through the mail. I don’t want HTML email, I want XHTML email that uses multiple XML name spaces! If the anti-HTML email crowd has its way, email messages will be forever stuck in the dark ages of document formatting technology.
Fortunately, as I mentioned earlier, the HTML email debate seems to be fading. HTML email is here to stay. Now we need to push for the next level.