-- Matt Noreen (email)

I think there is only one real advantage: paragraphs in an HTML mail wrap correctly.

-- J??zsef Sasv??ri (email)

Not only is text wrapping more predictable, but you can insert tables, either exported from a text editing or a spreadsheet/database program, and produce a simple, tightly formatted message that is easy to read without resorting to an attachment.

-- AOwens (email)

I feel quite differently about HTML that is written by a human and HTML that is generated by some of the (ahem) popular e-mail clients. I send most of my e-mail as plain text, but occasionally switch to HTML if I want, for example, to include a long ugly link. So instead of writing:

Hi Bob,

I think you can find what you're looking for here:

http://www.foofoofoo.com/barbarbar/bazbazbaz?quux=qoffle&grimblepritz=42

-Chap

I would write:

Hi Bob,

I think you can find what you are looking for here.

-Chap

It looks prettier to Bob, it does not stress his mail reader, and my original 140 character message is expanded by less than 50%. My simple HTML has not overridden any of Bob's type, size, color, layout preferences. This kind of HTML e-mail strikes me as only good.

It's also the kind you hardly ever get. I have a recent message in my inbox from an Exchange user, which is a two-sentence text of 338 characters. The HTML sent by Exchange is 6112 characters. Most of the extra size is taken up by its comprehensive overriding of all of my preferred type, size, color, and layout settings for my mail reader--all to no purpose, as the message is completely conveyed by the text. Not infrequently, the overriding types, sizes, and colors, which may for all I know look lovely to the sender, form a combination that on my monitor and to my vision are unreadable. On those occasions when I am reading mail over an X tunnel, these messages, already several kB in size, will occasion automatic font downloads to my X server, hanging my mail reader for upwards of 30 sec, at the end of which maddening interval I can finally read, in royal blue, an ostentatious typeface and a clunky size, the sender's intended message: no rehearsal Saturday. We'll talk tonight.

There's hardly any point in whimpering to the sender, who probably has no idea her mail program is burying every 100 bytes she types in 2000 bytes of HTMLjunk.

HTML messages good. HTML messages bloated with autogenerated HTMLjunk bad.

-Chap

-- Chapman Flack

I agree with Michael. From time to time I consider junking all incoming email with HTML in it. Everyone have the functionality on by default, but never take use of it. Email clients should in my opinion be installed with HTML formatted text turned off by default.

Most of your concerns here are client problems, not plain text limitations, as many of you suggest:

In-line graphics can be produced without HTML. This is supported by a MIME header: disposition = ( inline | attachment ). This works for many clients.

Background color and text size should be up to the user/recipient.

An email client should be able to wrap text in a displayed message properly.

Tables can also be formatted in plain text. If formatting or sharing spreadsheet data are needed, attach a PDF or the data file, or put it on the web and send a link.

As for long URLs i agree that HTML is a good option, although I'd prefer using a service like tinyurl.com. Both "hide" the end location, and introduce a security issue. Maybe the client should be able to chop off long URLs: http://www.foofoofoo.com/barbarbar/...

50% increase is a lot downloading email using a 9.6kbps cell phone.

-- Vidar Gundersen

Whilst I take all of Edward Tufte's earlier comments about text attributes very seriously the problem is that for all the thousands (millions) of emails received here I have yet to get a single one using HTML that is not spam. :-| Indeed have only ever received one HTMLised message that looked good on the screen and sadly that too was spam. For example, over night I received some 150 messages of which less than 10 were valid; the remainder were all HTMLised spam.

For the type of communicaiton that email is suited for there is no real need for bolding/italics, etc. If the document is long enough to require that sort of embellishment then create it in a word processor and attach it to the message.

I consider that HTML email is as much an abomination for textual communication as PowerPoint is for presentations. For my personal email I use a plain text mailer (pine, mutt, as the whimsey takes me) but I never ever use a HTML capable email reader. The security risks of HTMLised email far out weigh the benefits in my opinion (and just so you know I was for several years an email consultant with a major computer manufacturer). Looking at the raw content of much HTMLised spam the markup is there to obfuscate the message in a bid to get around anti-spam filters. All in all let's ditch HTML email.

Maybe E.T. will do for email what he's done for PowerPoint. The culprit in both situations is basically the same.

-- Trevor Jenkins (email)

For me this is a question of good design technique, not of HTML email via plain text. There is no question in my mind that HTML email will become the norm, as it offers so much more power to convey information than plain text, and that is the very purpose of a email - to convey information. Unfortunately this power is abused by spammers, hence it's current unpopularity.

A well designed HTML email can improve the ability to interpret a long email immeasurably, giving the user the ability to rapidly scan information, pick out salient points, ingore irrelevancies - all those aspects of informational design that are so important.

-- Richard Osborne (email)

I tend to agree with Chap, to be honest. I don't mind hand-coded HTML at all, nor do I have a problem with the bare-bones HTML that's generated by Mozilla Thunderbird and its cousin Netscape 7.

On the other hand, the code generated by Outlook is an utterly bloated mess, which seems to get progressively messier with each version of Outlook. Even this might not be so bad, were Outlook not the preferred mail client in most corporate environments...

-- codeman38 (email)

Something being missed here is that HTML was not, and in may respects still is not, a language designed for layot or typography. Rather, it was made for annotation and structuring of content. Insofar as it is used for this purpose, fine. But HTML is almost never used in emial to structure content, and nearly always used as a kludgy method for layout and typography. The results are, without exception (in my experience), shoddy and annoying. I send plaintext, and by default read plaintext.

I will specify the type that I use to read email on my computer. As for background color. If you think that using an off-white background makes text easier to read, fine: lower the contrast on your own monitor! But the antialiasing of screen fonts is optimized for a calibrated monitor and a white -- not off-white -- background.

-- Alex Merz (email)

Has anyone given any thought to the longevity of HTML emails from an archiving point of view? I almost entirely use text, so that my clients will always be able to view my past emails AND they take up less storage apace than HTML, making them more attractive to keep by my clients.

-- Lisa

I love the HTML in emails ! Especialy when someone has spend a lot of time on it ! When bandwidth becomes a problem you just didn't write crisp & clean HTML.

I use the emailprogramm from Apple (has got no name as far as I can see) but cannot make a HTML email. Any tips on how to do this without Outlook or so...

-- Erick Schluter (email)

Alex Merz makes a good point regarding the purpose of HTML; a point I ought to have made given that I was involved in some of the ISO work on SGML.

My biggest bugbear with HTML email and word processed documents is authors who specify fonts without any regard to the design purpose of that font. It has become very common now for display fonts (Helvetica and its look-a-likes such as Arial) to be used as text fonts. Reading pages of Arial-ised text hurts the eyes after a few minutes. Not for nothing has E.T. used Bembo for the text font in his books. Though if one must use a display font for text then Gill Sans (as he uses for heads, etc) is significantly better than Arial ever will be.

Typographic design is not something for the masses to do themselves. There are subtle rules involved the breaking of which show up as glaring faults even to the most infrequent of readers. Would be better (easier on the eye) to stick with using a typewriter font until one has learnt those subtlities. As with all things less is more.

If HTML in email was there for purely structural reasons then it would be fine. Sadly it is implemented and marketed as a procedural markup scheme no better than UNIX troff.

-- Trevor Jenkins (email)

The best primer I've found for HTML.

-- Niels Olson (email)

The source for the HTML lesson is Software Engineering for Internet Applications by Eve Andersson, Philip Greenspun, and Andrew Grumet at

http://philip.greenspun.com/seia/

-- Edward Tufte

More than 12 yrs ago, Steve Job's NeXT computers came with a client called NeXTMail, that supported rtf emails (actually rtfd, an extension). As a result, emails were like word processing documents, and at that time rtf was a pretty standard document format. The extensions allowed inserting images, and something they called Lipservice, which allowed you to insert a voice recording. Obviously, there's some bloat involved, but I did send/receive NeXTMail over 14.4 modem connections in 1994. In the interim 10+ yrs, I've not seen anything to match it yet. I do notice that Outlook has an rtf format option, which I've never sent and don't recall ever receiving.

-- Michael (email)

It has become very common now for display fonts (Helvetica and its look-a-likes such as Arial) to be used as text fonts. Reading pages of Arial-ised text hurts the eyes after a few minutes.

I've discussed this very issue with a number of colleagues (who generally know nothing about typography beyond their own preferences), and almost without exception, people who read text on-screen prefer sans serif typefaces. The general consensus seems to be that serifed typefaces are much harder to read on-screen than sans serifed typefaces. So much so that I have a hard time convincing people to use serifed fonts in material intended for print.

In fact, even I find that fonts like Times New Roman or even Bookman are typically less readable than Verdana or other fonts that have the heavy lines of sans serif fonts and only the occassional serif.

I wonder if anyone has done a study of the impact of low-resolution screen displays on the old print rules of typography. Is it possible that sans serif typefaces are more readable at 72x72 ppi than serif typefaces, or is it something else: maybe the sans serif fonts are typically larger, or their ascender height to x-height is typically greater?

-- Thomas Hopper (email)

In response to Thomas Hoppers question regarding fonts, I think that you'l find that low resolution typography began with the advent of the laser printer and has been extended to displays. The effect of rasterization on fonts has been studied since the advent of digital type sometime in the late 60's or early 70's (digital templates for photo-typesetting). The low resolution rendering of traditional letterpress typefaces such as garamond, bembo, times, etc led to the development of 'hinting' in type-1 fonts and later in truetype fonts. Hinting is a process by which fonts have an improved legibility at low resolutions. This is necessary because the path followed by the font outline often crosses through a pixel boundary and the pixel can be either on or off (or more recently a shade of gray using anit-aliasing). The hinting program decides whether the pixel should be on or off at the given resolution to optimize the appearance of the character or glyph. This was done to provide a what-you-see-is-what-you-get approach to page makeup, even though it is arguably not the case. Another approach was to develop fonts that were developed for low resolution devcies and might even fit the raster matrix with an even number of pixels (e.g. Charter for the laser printer, Chicago, New York for the Macintosh display). However while the chief output of the computer systems continued to be the printed page, the focus was on better rendering of print fonts on the screen for WYSIWYG displays.

With the rise of the internet came the fonts optimised for the low resolution display - Georgia, Verdana, Tahoma, Trebuchet, Vera and their antecedant the much maligned Arial. All of these fonts have their outlines optimized for on screen display and as anybody who has tried to use these fonts for printed material knows, they are not good fonts for printing---The set is too wide for easy reading. The differing resolutions show one of the dangers of getting too comfortable with the WYSIWYG. The fonts that look best on screen are not likely to look as good on paper and vice versa. This fundamental dichotomy has been at the heart of why desktop publishing has rarely reached the standards of professional typesetting - what you see is <not> what you get. The professional typesetter generally uses a two step process: mark up the text in a program that uses a good screen font and then produce a final copy for preview or printing using a good printer font - the fonts need not even resemble each other. The professionals that do use WYSIWYG tools often have great experience that prevents them from being mislead by the screen representation.

So in answer to your question, it <has> been studied and type designers have tried to address readibility on screen. What has not been achieved, and likely will not be achieved until screen resolution matches printer resolution, is the typeface that looks good on screen and good on the printed page.

Which brings us back to HTML in email. The design of HTML was based on the idea that the fonts available at the client were not known to the server, hence the client was allowed to pick the fonts. The mark-up was designed as a simple way to emphasize information, to allow scientists (the original audience to communicate). The more recent control of typefaces and layout are more add-ons designed to serve the designers of (mostly) commercial material.

I personally prefer not to have HTML in email mostly because of the rise of the recent add-ons. The attempt to control fonts and representation on a remote client is unwise and often fails because of assumptions. If the HTML were simplified e.g. HTML 1 with simple character control (bold italics etc ) and the inclusion of images, I would not object. More complex than this and a better option is to generate a PDF and send that instead. Most email is ephemeral and worth no more trouble than typing it in a plain text format with typewriter typography

-- John Walker (email)

Previous responses have touched on most of the reasons I hate HTML Email. The biggest one missed arises when I'm reading through several Emails, say from an active Email list or a page like this one. After reading several messages approximately formatted like each other, I find it very grating to suddenly come across one that looks completely different because of its HTML roots. It might be okay if all HTML users used the same style, but that rarely happens because the Email clients often make it easy to tune things to meet the user's fancy.

I suppose someone could argue I should join the 21st century, but if I ever find a collection of short stories where each story is printed in a new font, new size, and on different paper stock, I'll have to buy it just so I could burn it.

-- Ric Werme (email)

I have tried to summarize a number of the issues regarding HTML email in a short document: http://www.american.edu/econ/notes/htmlmail.htm In all, I think considerations of courtesy speak strongly against HTML mail.

-- Alan Isaac (email)

Response to HTML in Email: terminology

A note on correct terminology: "With the rise of the internet came the fonts optimised for the low resolution display - Georgia, Verdana, Tahoma, Trebuchet, Vera and their antecedant the much maligned Arial. All of these fonts..." incorrectly uses the term "font" -- the writer means "typeface". A font is a particular instantiation of a typface with a particular size and perhaps italics or other modification. This comes from the days of hand-set type where each drawer contained a font, e.g., 10pt Bembo, 10pt Bembo italic, 10pt Bembo small caps, 11pt Bembo, etc. MSWord and other computer programs that incorrectly label typefaces as fonts out of ignorance are largely responsible for the proliferation of this error.

-- R. W. Crowl (email)

I have the best of both worlds; I'm blessed with an email/news reader (Turnpike) that displays email as plain text by default, with a pair of buttons to select from the plain text/HTML multipart options in the email.

-- Derek Cotter (email)

I thank R W Crowl for pointing out my loose use of the terms typeface and font. The correct usage is indeed that a font is a particular instance of a typeface. This usage arose in the age of lead type when the typeface was somewhat modified at each design size so that a new term (fount and, later, font) was required to describe the typeface at each design size.

In my defence, only to plead for leniency not to declaim guilt, I submit that the majority of computer type is generated from a single master that is scaled up or down for different point sizes. This in imitation of the phototypesetting process that was dominant when desktop computer typesetting was developed. That master could be considered a font, being digitised from a single instance (usually 14 point) of a typeface. This may have been a contributing factor to the confusion as to whether or not type on a computer screen was a font or a typeface.

With the rise of multiple master typefaces with embedded instructions for generating size-specific fonts, the previous lax use of font and typeface as interchangeable terms deserves to be abandoned and a return to the orginal usage seems appropriate.

-- John Walker (email)

Does anyone have any good suggestions on how to communicate data via email effectively when formatting is not an option? I am thinking specifically about data that will be read on a Blackberry or similar device, where text-only display is possible, which clearly limits very significantly the ability to show any very meaningful relationships. I work in finance and there is strong demand for financial market data via email for display on a Blackberry and if anyone has, or has seen, good examples of how to do this effectively, I would appreciate any and all suggestions. The most obvious approach would be to do as the financial newspapers do in displaying data but I would be curious to hear of alternative suggestions.

-- Will Oswald (email)

+
|
|o
|o o          o
|ooo o  o    oooo
|ooooo  oo  ooooooo 
+-----------------------+

-- Jorn Barger (email)

Making use of a line-by-line printer, John Tukey once designed some little statistical graphics that looked much like Jorn's graph above.

-- Edward Tufte

Jorn's example worked because he enclosed it in <pre> tags. If he hadn't (but had used <br> tags instead to produce line breaks), it would have have looked a mess,

+
|
|o
|o o o
|ooo o o oooo
|ooooo oo ooooooo
+-----------------------+

or, if not a mess then potentially misleading, because the things that are supposed to line up would not line up.

I don't possess a Blackberry so I don't know how much control either sender or the receiver of information have over how it is displayed, but unless there is the possibility of specifying a monospace font (Courier and Monaco are the only ones commonly found on modern computer systems) then ASCII art won't work.

-- Athel Cornish-Bowden (email)

I inadvertently cheated in the above example, because I forgot to replace the spaces with fixed spaces (&nbsp;), but even with fixed spaces it doesn't look right,

+
|
|o
|o o          o
|ooo o  o    oooo
|ooooo  oo  ooooooo 
+-----------------------+

because the different characters have different widths with most fonts.

-- Athel Cornish-Bowden (email)

I did some checking and it does not appear that it is possible to specify a monotype font on a Blackberry, which then severely limits my options. Thank you for the suggestions though.

-- Will Oswald (email)

Brian Krebs in his outstanding computer security column "Security Fix" at the Washington Post provides some strong reasons for avoiding HTML in email: link

Here's part of his column, which also provides information about how to reset email programs to avoid embedded HTML code:

"Last week, Microsoft issued a patch to fix an extremely dangerous flaw in Windows that cyber crooks could use to break into your computer just by getting you to open an e-mail. Let that sink in a moment: Merely by reading a specially crafted e-mail, you could open your Windows machine to attackers, who are then free to install malicious programs, and view, change or destroy your personal data. Try not to be too frightened by the news this week that instructions showing bad guys precisely how to exploit this flaw were posted online for the whole world to see."

"This was hardly the first time Microsoft issued a patch to fix a similarly serious and easy to exploit vulnerability. But it gives Security Fix a good excuse to remind readers that viewing your e-mail in anything other than plain text mode is asking for trouble on a Windows computer."

"Most e-mail software comes configured to relay messages both in text-only mode and HTML format, which allows for the rendering of graphics and other Web-based content. But blindly accepting HTML content from third parties is a bad idea on a number of levels. The most dangerous threat is HTML content that enables the silent downloading of malicious software. In addition, even if you've never replied to a single piece of junk e- mail, spammers can tell if they've got a working e-mail address if you merely view one of their HTML-based e-mail ads. If young children use your computer or if you'd rather not look at spam touting graphic images from adult Web sites, disabling HTML is a must. Also, e-mail phishing scams often are made much more convincing when rendered in HTML."

"Likewise, sending e-mail in HTML mode is just a bad idea all around, and these days, it's a recipe for making sure the messages you send get caught in the recipient's junk mail folders. That's because in an effort to bypass anti-spam technologies that look for spammy words in the body of the e-mail, a huge percentage of spam now arrives embedded in HTML code and in images. . . ."

The column is also accompanied by an extended commentary on HTML in email.

What are the losses of setting an email program to avoid spam with embedded HTML code?

-- Edward Tufte

Dear all,

I appreciate all the various angles in the above discussion. Fully realising all the drawbacks of HTML mails (security, changing appearances, several fonts/typefaces etc) I find that HTML provides significant flexibility in day to day work.

My work being in quality and product development in an international company, I communicate a lot using graphic elements. I find that the flow of a message demands a graph at certain specific points. If I have to revert to attachements, I feel I can loose the momentum of my story (recipient has to open the attachement, takes time etc etc). If I use text I feel very contrained (in the applications that my company makes available to me). So I am happy that HTML allows me to insert freely whatever graphic element I choose at a position that I choose.

I appreciate the contribution of Derek Cotter where he points to a very fundamental concept: his email client allows him to choose between text and HTML. Thus deciding for himself what formatting is appropriate and what content he can accept to loose.

One interesting, and potentially dangerous feature of modern email clients is that pasting an Office element (e.g. an excel graph) pasts the entire application rather than only the graph. Most of you will be familiar with this. In my business environment I have wittnessed some interesting events because of this. Including a supplier who used a random number generator in excel to arrive at the most beautiful evidence that his parts statistically complied with the specification...

Paul van Oppen

-- Paul van Oppen (email)

I have only one (very minor) annoyance as a consequence of having my mail client strip HTML: images do not render in my emails and I have to open them seperately. Messages like company newsletters usually look a little strange, because all the fancy headers and logos are gone, which can do strange things to the layout. This niggle is more than outweighed by not having messages in 18pt Comic Sans inflicted on me.

Google's Gmail handles HTML mail in an exemplary fashion - it blocks HTML images by default, thereby defeating all the nasty spammer tricks, but offers links at the top of the email to show the images, and to allow images from this address in future. URIs in the message are automagically rendered as links, even if they were sent as plain text. Another nice touch is that if an email has been sent with an image file as an attachment, it displays the image at the bottom of the email text - good for pictures from technophobe relatives.

-- Jakob Whitfield (email)

HTML email is a very widespread marketing tool for opt-in mailing lists in commercial organisations. Whilst end-users might not appreciate unsolicited HTML email, it does enable better presentation for certain types of mailing which the end user will find far easier and more pleasant to read than plain text.

Unfortunately, Microsoft has given us another reason why this shouldn't be used, by switching Outlook 2007's HTML rendering engine from that of Internet Explorer (as used in all versions of Outlook prior to Office 2007) to the one used by Microsoft Word (which is the default editor for composing HTML emails in Outlook).

Full coverage of this can be read at Campaign Monitor, where they demonstrate the problems this switch causes. It isn't unfair to say that Microsoft's decision has taken HTML email back by about five years. I brought the issue to the attention of former Web Standards Project lead Molly Holzschlag, who has close contact with Microsoft's IE team and she has written up the response she received, but the short version is: HTML email should now be considered (even more) harmful.

-- Ben Darlow (email)

I share the opinion of many of the previous respondents. In fact, I used to rant to no end about HTML mail. Then—THEN!—I went to work for a certain federal government. There, standard practice seemed to be to send an email with no subject line and no explanatory body text, only a single attachment that was——

Now, I know what you're thinking at this point; it's Word. Everyone's gotten a Word attachment in their email correspondence life. There are numerous unix tools that you can hook in to various mail clients to render a Word document as plain text to combat this. Well, sure, I got a lot of those, too, but in this case, dear reader, the common attachment was our good friend PowerPoint. With a single slide composed of nothing but text in 14-point Arial.

After that, HTML mail is merely a mosquito.

Ric Werme makes an interesting point above. Letterhead and document design are useful in print correspondence because of the nature of the storage. If I want to find the print letter from Steve, his letterhead will help me find it in the pile on my desk. But if I want to find the email from Steve, I just have to search for "Steve." Also, Steve's print letterhead probably doesn't blink.

This all may merely derive from a preference for reading print media that will disappear a generation from now.

-- Patrick Carr (email)

A similar thread over on Reddit stemming from an article on the effect of typeface in e-mail.

Boredzo: There's a lot of HTML email out there, even after you throw out spam.

Taladar: Not if your definition of spam includes every HTML email.

-- Niels Olson (email)