The document below taken in total from http://www.american.edu/cas/econ/htmlmail.htm Sunday, 2003-06-01, 06:02pm.
First posted: 2002 Feb 15
Last modified: 2002 Sep 20
Current location: http://www.american.edu/cas/econ/htmlmail.htm
HTML mail should be an act between consenting parties. Unless you know that you are sending writing to someone who does not mind HTML email, send plain text. There are many people who simply do not like to receive HTML email, others who find it to be a personal inconvenience, and others who must literally pay for the greater bandwidth consumed by HTML email. All of these considerations become particularly strong on newsgroups and mailing lists (with their great variety of participants from around the world), where the use of HTML email is often considered ignorant or rude.
In all other circumstances: TURN IT OFF! Sending unwanted HTML email signals that you are either ignorant or rude.
The norms of internet communication are that email interaction takes place by means of plain text messages, except in the situations indicated above. Sometimes these norms are explicitly stated, but most of the time they are implicit. When you use HTML email, you indicate your ignorance of these norms. When you participate in email lists or newsgroups, you will quickly be informed of these norms. At that point the excuse of ignorance disappears.
If your excuse is that you have not learned how to turn off HTML in your email client, this is a different kind of ignorance that you can easily overcome: you can find online help, or you can ask a friend or colleague.
Except in the situations indicated above, HTML email disregards the preferences of your interlocutor. Such disregard is of course rude. But that leaves open the question of why your interlocutor may prefer plain text. Here are a few possibilities.
I might be using an email reader that does not support HTML mail. Many people still prefer to use small, fast, text-only email agents.
I might be configuring my email reader to display text as I desire to see it. If you send plain text, I can configure my email agent to display this text as I desire. I can use the font, font-size, and color scheme that make it easy for me to read. If you send me HTML email, you will often force you formatting preferences upon me. Additionally, I will have to waste time adjusting to the new format, looking for the information that I care about in your email. So you have reduced my comfort in reading and you have wasted my time.
And that is not all. Many professional communications take place on email lists and in newsgroups. HTML email there acquires a different level of rudeness. First it violates the norms established for such interactions, and it is always rude to enter a group conversation without respecting its norms. Second, these norms are well founded: they are designed to save the participants time (as discussed above) and money. Many people still pay per minute to download their email over slow modems, especially if the communication is international in scope. If I must pay by the minute to download your needlessly bloated HTML email, you do not just cause me discomfort and waste my time—I have to pay real money for your rudeness. Finally, the bandwidth issues are particularly acute for people who read their news and email on a personal digital assitant, a practice that has become quite widespread.
Dislike of HTML email is so wide-spread and the drawbacks of HTML email are so well-known that it may seem surprising that there is no RFC addressing it directly. (Indeed, that lack was my motivation for writing this document.) The core reason, I surmise, is that the acceptability of HTML email depends on the environment in which it occurs, as discussed above. The arguments are not against HTML email per se, but against sending it to a recipient whom you do not know to consider it acceptable.
Nevertheless, RFC 1855 http://www.dtcc.edu/cs/rfc1855.html addresses internet standards for email, and it clearly presumes that plain text is the standard for email. Especially relevant are the request to limit bandwidth use, the suggestion to restrict the character set to ASCII and, related to this, the suggestion to use ASCII symbols to connote *emphasis* or _underlining_ in your text. (In an appendix, I quote a few pieces of RFC 1855 to make this point. However it should be clear that the arguments supplied above apply even if we disregard this RFC.)
Many people who handle a lot of email assume HTML mail is spam and filter it on that assumption. As this practice becomes increasingly widespread, sending HTML mail becomes increasingly inefficient: your message will be postponed or even deleted because of its format.
Anyone who handles a lot of email should be concerned about efficiency in communication. Even if your own volume of email is small, you should still support efficiency in communication as a courtesy to your interlocutor. Some basic norms of email communication have evolved to promote this efficiency. Quoting practices are among these—especially selective quoting, interlineated responses, and standard quote indicators. These established practices again favor plain text over HTML mail for two reasons: plain text editors are more powerful and faster than HTML editors, and standard quote indicators are more likely to be handled intelligently by text editors.
An additional consideration is particularly important for people who handle large quantities of email and, correspondingly, for any newsgroup or email list. HTML mail reduces the useability of old mail archives. Search of text messages is much faster than search of HTML messages. (Similar considerations support selective quoting over indiscriminate quoting, since the latter leads to too many matches during archive searches.)
Selective quoting is both a courtesy and a communication device. Quote only the text that is relevant to your response. The quotation should be selective and to the point. Editing for selective quoting is much easier in plain text messages. If you communicate in plain text, you can speed up your own response and assist any responding reader of your email.
When responding to more than one comment in an initial email, standard practice is to place each response after a relevant section of quoted text. This allows the reader to more easily see how the conversation is taking place: the response is adjacent to the text responded to. Editing for interlineated responses is much easier in plain text messages.
>> This text was quoted in the email I am responding to. > This was original text in the email I am responding to. This is my response to the two quotes.All modern email agents will correctly nest standard quote indicators in plain text messages. Note how the level of quotation is indicated not only by the standard quotation scheme (i.e., by the use of >) but also by the color of the text, which makes it very easy to see the structure of the message. All modern email agents will colorize plain text in response to the standard quotation scheme. This is yet another courtesy to your reader that you can provide, if you stick to plain text in your email.
Comment: users of webmail and of older email agents cannot expect the helpful colorizing of text in response to the standard quoting practices. However the quote indicators still provide the same information about the structure of the message.
HTML mail can be useful in specific settings. Groups of people can reasonably agree to use HTML for their email communications. However HTML email can impose costs in lost readability, reduced convenience, higher bandwidth use, and reduced security. Therefore the use of HTML should be restricted to consenting parties, where it is understood that consent can be given implicitly as discussed above.
ASCII Ribbon Campaign.
Boyd, G., Configuring Mail Clients to Send Plain ASCII Text.
Delorie, D.J., 1999, Why HTML Mail Is Evil.
Guckes, Sven, HTMLized text. (An oft cited discussion.)
Nolte, Mike, HTML-Mail ist gefährlich und schädlich
RFC 1855 http://www.dtcc.edu/cs/rfc1855.html.
RFC 2822 http://www.faqs.org/rfcs/rfc2822.html
RootsWeb, Problem Solving: Sending Messages in Plain Text
Use symbols for emphasis. That *is* what I meant. Use underscores for
underlining. _War and Peace_ is my favorite book.
This of course presumes ASCII mail, not HTML mail.
Do not include control characters or non-ASCII attachments in messages unless
they are MIME attachments or unless your mailer encodes these.
HTML of course has no such character set restriction and cannot be presumed to.
Limit line length to fewer than 65 characters and end a line with a carriage
This of course presumes ASCII mail and is generally violated by HTML mail.
The line length restriction may seem dated, but in fact many email clients
will wrap at 70 characters and a slightly shorter line-length allows for
the standard quoting conventions (e.g., >).
Remember that many people pay for connectivity by the minute, and the longer
your message is, the more they pay.
As discussed above, HTML mail is always much longer than the ASCII equivalent (at least for European nations). One reason for this is that a text copy of the mail is always included with HTML email, because some email clients do not read HTML. Another reason is that the HTML codes require bandwidth. Finally, often HTML email will include graphics, which are usually unwanted by the recipient (as well as being a security risk).
'Reasonable' expectations for conduct via e-mail depend on your relationship
to a person and the context of the communication. Norms learned in a particular
e-mail environment may not apply in general to your e-mail communication with
people across the Internet.
It is a norm on most active email lists and on most active newsgroups that only ASCII mail shall be posted.
Copyright © 2002 Alan G. Isaac
Permission to redistribute this document is granted on the condition that the document be distributed in its entirety.