The death of plain text email

Robin Whittle Last update 2015-09-24

HTML email sucks, but we are stuck with it

This is a new beginning for a page which I created in 2001 and had not updated by September 2015, entitled "Problems with HTML Email".

That page appears below, unaltered, as an historical document.

Most of it is still true - HTML emails have numerous problems.  However, it seems that I and everyone else needs to send them now, since many people are using email clients which cannot properly display or reply to plain text emails.

A plain text email involves lines typically limited to some readable width, such as 72 or 80, with exceptions for long URLs.  The spaces and line endings of what the user saw when they composed the message are sent verbatim, and should be displayed in the same way.  As long as the sender composes with a fixed width font, and the display uses a fixed width font, the recipient sees exactly the same text and formatting as what the sender composed, with the exception that most receiving clients automatically find a word starting with http:// and display it as a clickable hyperlink.

This made it possible to simply paste a URL into a message, and the recipient would automatically find this to be a clickable link.

There is no colour, bold-face etc. (though some recipient clients annoyingly displayed *xyz* as bold xyz).   Some recipient clients, by default, replaced emoticon text elements such as ":)" into a smilie graphic, which I think detracts from the minimal ASCII-art charm of the plain characters, and involves arbitrary aesthetic choices invisible to the sender and recipient, and typically beyond the control of both.
It also enabled complete communicative freedom regarding formatting, such as arbitrarily complex tables, indentation etc.:

Selahammahlekoth, Chushanrishathaim and Mahershalalhashbaz
are long names from the Bible.  Amy, Ava, Ben, Sam and Max
are shorter names not found in the Bible.  Blah blah blah
blah blah blah blah blah blah blah blah
.  The limitations
on this principle are the behaviour of:

  1 - Huey.

  2 - Duey, except on on Sundays.

  3 - Louie, whose behaviour depends on the phase of the
      moon, the price of eggs, how many angels are found,
      by careful experiment to be capable of dancing on
      the head of a pin and several as-yet undetermined

However, many email clients (and users are typically unaware of what is happening, and unwilling or unable to choose a better client, or configure it to behave better) display such a message in a proportional width font, which screws up the formatting of indents, any kind of tabular layout etc:

Selahammahlekoth, Chushanrishathaim and Mahershalalhashbaz
are long names from the Bible.  Amy, Ava, Ben, Sam and Max
are shorter names not found in the Bible.  Blah blah blah
blah blah blah blah blah blah blah blah
.  The limitations
on this principle are the behaviour of:

  1 - Huey.

  2 - Duey, except on on Sundays.

  3 - Louie, whose behaviour depends on the phase of the
      moon, the price of eggs, how many angels are found,
      by careful experiment to be capable of dancing on
      the head of a pin and several as-yet undetermined

I think many of these clients use a sans-serif font, so there is no visible difference between upper-case I and lower case L.  These stylish fonts, when rendered in a small size, are difficult to read for people with astigmatism.  Such problems do not occur with Courier or any other decent fixed width font.

Copy and pasting from some web page into a plain text email editor strips out all font name, size, colour, bold, italic, underline, hyperlink etc. information, which is typically a blessing.

In an HTML email, extra work is typically required at the compose stage to make some text appear as a clickable hyperlink - and many people either don't know how to do this or don't care to do so.  This means the recipient needs to copy and paste the text into their browser, rather than simply click it in their email client.

Email clients used to handle plain text emails in a standardised way for replying - by including the original text, with a "> " at the left, so the sender could retain some or all of this quoted text, adding their own lines under the relevant sections, without such "quotation marks".  This however raises problems of line length growing unacceptably, especially with multiple reply cycles.  A Windows email client program from the 1990s, Pegasus Mail, used to do a great job of intelligently reformatting such text, if required.  Netscape and later Mozilla Thunderbird generally make a mess of the text with their reform options.

This is a fundamental problem with plain text emails.

Another is that some display devices are too narrow to support the full line length used in a plain text email, such as 72 characters.  One response to this was to make "format-Flowed" the default method of sending "plain text" emails from Thunderbird.  This destroys the ability to format text freely, as above, and instructs the client to ignore line endings and reflow the text of whatever is considered a paragraph to suit the display window.  I was one of the people who argued that it was a bug to make this the default, but whoever controls these things retains it to this day, and the bug was reported in 2001:

Call me grumpy if you like, but the ability to use a simple, long-established, method of email communication no longer exists, unless one knows the reciepient's client can handle it.  This is due to sloppy programming and thinking, and choosing fancy, overcomplex, eye-candy features as defaults, and ultimately as the only mode of operation, for email client software.

Problems with HTML email

This page contains some arguments as to
  1. HTML email is often more trouble than it is worth.
  2. Why email client programs should default to sending "plain text" emails, displaying in a fixed-width font, with on-screen visible WYSIWYG (What You See Is What You Get) wrapping to a sensible margin such as 72 characters, with long URLs not being wrapped at all.
There are also some links to relevant pages.

Robin Whittle    Last update 17 August 2001.

Back  to the sys-admin page for more computery things.
Back  to the main First Principles page for all sorts of interesting things, such as my 71 foot Sliiiiiiiiiiiiiiiiinky and some intriguing old photographs.

Search engine bait:  HTML email is evil.  Ban HTML email.  HTML email problems.  I hate HTML email.  ASCII ribbon campaign against HTML email (is there a site for this??).


This debate is a general one, but my specific focus is the future of the Mozilla project:  Some years ago (January 1998), before Netscape was purchased by AOL (hisss!) the company made a bold plan for developing the next generation browser (and HTML composer, email, Usenet client, Swiss Army knife etc.) to replace its Netscape Communicator/Navigator 4.x series.  Rather than follow the usual secret internal commercial development path, Netscape would develop it on an Open Source basis.   This means the source code for the new browser would be public and covered by a licence which means, in a nutshell, that:
Anyone could use the source code to make their own programs, but if they released the program in any way, including by selling it, they must  make all their source code publicly available under the same terms.  
(The exact nature of Mozilla's licence can be found at and more info on open-source software can be found at and . )

Mozilla is a separate organisation to Netscape (now owned by AOL) and while I think most contributors to the Mozilla project are paid by Netscape, anyone at all can contribute, according to the arrangements for each part of the project.  

Mozilla is the basis for Netscape 6.   Mozilla is also the basis for any number of browsers of the future - so I think it is important that it reflect the communication needs of most users.  I regard email as the number one application of the Internet.  Yet I think that the current arrangement of email clients and general standards of practice with email is a big mess.  

There are two newsgroups of interest to this debate as far as Mozilla is concerned.  These are the Mail/News and Editor newsgroups, both of which are listed at:
If your browser is Netscape (maybe MSIE?) you should be able to access these newsgroups with the following links.  If you don't know what newsgroups are, please refer to the above URL.  They are also available as mailing lists via the above page.
Both these are available direct from the server, so you can probably just click on these, download the headers, read and contribute. But be sure to read the above page for the guidelines before contributing.  These newsgroups are only about Mozilla, not Netscape 4.x or anything else.  You can download the latest versions of Mozilla for Windows, Mac, and various Unix flavours at the Mozilla site. You can also download the entire source code and compile it yourself!  (Its not trivial on Windows, see my notes on news:// in December 2000 for some hints.)

In March 2001, some Mozilla people asked me to write about why Mozilla should send plain text emails rather than HTML by default.

In August 2001, I wrote to the Mail/News newsgroup with a rant as to why this should be the case.  This is the first major body of text below.

At that stage, I assumed that Mozilla used the HTML editor and sent HTML emails by default.  After I sent this, I was told that Mozilla sent plain text by default - so I retracted my rant.  Then I found that it uses the HTML editor and then, by default, converts this to plain text (after warning the user and giving options to send as HTML or plain text and HTML), so I discussed it some more and re-instated my rant.

In the text which follows, you only see what I wrote, which includes some quotes from other people who seem to disagree with me about one thing or another - but who also agree with me about some of the things I am arguing for.  To see the full debate, you must look at the Mail/News newsgroup itself.

I am not trying to present a one-sided view of the debate - I am only putting on my website what I wrote.  Be sure to see the Mail/News newsgroup for the full debate - which continues after the contributions listed below!

The debate also continues on the Link mailing list, under the thread "Mozilla - slow progress".  The Link list home page is here and the August 2001 archives are here: .

Rant 1 - A list of problems with HTML email and why plain text email should be the default.

     Subject: Plain text vs. HTML email
        Date: Fri, 10 Aug 2001 23:45:51 +1000
        From: Robin Whittle <>

To the Mozilla developers, the Link mailing list and other people who
might be interested.

I will soon add this to:
where I will keep it updated and add links to relevant resources.

I was asked on this newsgroup (netscape.public.mozilla.mail-news) last
year to write about why plain text email should be the default for email
clients, rather than HTML.  Its such an obvious thing to me, that I
can't imagine why anyone needs to be convinced.

Anyway, here are some arguments.  I guess most or all of what follows
goes for Usenet as well as email.   I get frustrated at times that so
much effort goes into making things that look impressive at first, but
in fact lack depth and reliability - and are then presented to everyone
as the default way of doing things.  The result is a ***lot*** of
frustration, wasted time and effort and miscommunication. 

I understand that quite a few people on this newsgroup share my beliefs,
but find it hard to convince some management people about the benefits
of simplicity.  I hope this piece helps!

Plain text emails, when written and read in fixed width fonts, and with
good, WYSIWYG text wrapping, are superior for most people, and should be
the default arrangement for all email clients as opposed to HTML, for
reasons including the following:

1 -  Plain text is simple and understandable - nothing could be simpler.
     A character is a character.  A newline is a newline.  What
     you type is what you see and what the recipient receives.  There
     are no ways, in a proper system, for things changing or being
     obscured, provided sensible right margins are observed in the
     original message.

2 -  You always see on screen *exactly* what is going to be sent.
     (Provided both ends use a fixed width font.  Proportional
     spacing fonts make it impossible to reliably lay out text
     for communicative purpose, such as this dot-point indenting
     or ASCII diagrams.)

3 -  Not counting emoticon graphics and these damn quote vertical lines
     (which Mozilla has now) in the recipient's client, the recipient
     will always see, on screen and on paper, exactly what you sent.

     (OK, I have said the same thing three ways - but email is the most
     important aspect of the Net as far as I am concerned, and it is
     vital that it be direct and pure - not subject to unseen changes
     glitches, complications etc.)

4 -  There is no dependency on fonts - provided that the Internet
     standards are adhered to (and so Microsoft practices must be

5 -  The messages can be displayed with minimal fuss on mobile devices
     and text consoles with no graphics capabilities and small
     screen sizes.

6 -  The system *always* works, whereas HTML may not.  For instance
     I received an HTML email which was a completely black page -
     black text on a black background.  I was able to sus it out, but
     most people would not.

7 -  Plain text is easy to read, and never plasters a printed page with
     expansive, soggy ink just because the writer thought that pink
     text on a very dark background graphic looked cool.

8 -  Less bytes and sent and stored than with HTML. 

9 -  There are no attachments, multi-parts to messages etc. unless
     there is a real need to attach a file.  So the user is never
     left wondering whether they have missed something - the message
     is just text, all in one piece.

10 - For the great majority of users, plain text is at least as
     communicative as HTML, and those who know how to use HTML can
     always decide to send HTML emails actively and wisely.
     (I am not saying HTML email should be banned - just that it should
     not be the default and should not be encouraged for general use.)

11 - HTML can have formatting which will not wrap to screen or
     page margins, while if sensible 72 line limits (or longer for
     URLs and quoted text) plain text is used, the client will
     always be able to display and print it without any wrapping

12 - HTML emails can specify fonts which are non-existent fonts on the
     recipient client, or fonts which are too small to read on screen.

13 - Complex HTML emails with attached files for graphics etc.
     can be hard to forward.

14 - There is a danger of complex email formats such as HTML making
     email with attachments or multi-parts the norm.  Virus and other
     security threatening things can easily lurk in all sorts of
     special file formats, and especially in HTML.  So making people
     get used to receiving emails with complex file structures they
     don't understand makes it harder for them and everyone else to
     be wary about genuinely dangerous emails.

15 - Likewise - you can't get a virus or a web-bug from a plain text

16 - HTML emails with graphics files may be very large compared to what
     the unsophisticated sender thinks they are.  I found a web page
     today with two B/W images which appeared small on screen, and
     should have been 50 k bytes each at really high quality. 

     In fact the images were raw scans and were huge in terms of
     pixels and bytes 1.4 megabytes total!  The web site creator
     was obviously oblivious (though I now mailed him cleaned up
     re-sized images which look a lot better).

     So if a web designer can put up a clueless page like this, where
     it costs them money each time someone looks at it, what is to
     stop them sending the same small page to someone as an email?

     With a cable modem, they wouldn't even notice that the email was
     2 megabytes.  But pity the poor recipient on a 28k modem or a
     9.6kbps (if you are lucky) GSM mobile link. 

17 - HTML emails are impossible to deal with in many mailing list
     situations.  They make a mess of digests and archives, since the
     HTML cannot be displayed properly as part of a larger page, even if
     it was an HTML page, since the HTML itself involves text colours
     which rely on a background colour which is impossible to set
     in the larger page.    Obviously raw HTML in a digest makes it
     really hard for anyone to read, as well as greatly increasing
     the digest size.

18 - HTML emails may be hard or impossible to quote from for a
     client configured to send plain text.  Netscape 4.78 (in non-HTML
     mode) regularly produces a blank Compose email when it is supposed
     to begin with quotes from an HTML email.

     How does one quote text in tables, for instance?

19 - There are all sorts of security problems with HTML email, which
     can best be resolved by having the recipient client refuse to
     render HTML at all.  For instance the inclusion of a tiny image
     file from a remote server tells the server exactly when and
     approximately where it was opened.  Likewise Javascript.

     There can be Javascript embedded in the HTML, which poses all sorts
     of security problems for clients, and web-mail systems in
     particular.  Badly written email clients can be prone to complete

     just be the email being rendered.  Even if this bug is fixed, the
     Microsoft client is still vulnerable to any (HTML) email starting
     a file download from a remote site! 

     Because HTML emails are a threat to the security of the user's
     computer and their sanity, the best policy is to never render
     HTML emails.  Then, this means that users who are by default (that
     is they have made no choice, and probably have no idea what the
     terms "HTML" or "Computer Security" mean) send a message via
     HTML email, then they don't know that the recipient will get some
     kind of text subset of what they wrote.

     A guide to turning off HTML email in various clients is at:

20 - Turning these security problems around to the software vendor,
     lets say a company asks: "How can you assure me that this email
     client is not going to be a security threat to our computers."

     Its a pretty hard question to answer if the client does anything
     with HTML.   If it only displays plain text, or converts HTML
     so something viewable without any Javascript, any external
     references and it uses very clearly designed and restricted ways
     to handle anything non-text (such as attachments) then you might
     be able to give the potential customers some solid assurances
     about security.

     These really are the bad old days of email - with so many ways
     malicious emails can wreak havoc.  Its the propellerhead
     featuritis phase, and this rant is intent on closing the lid on
     this dangerous chapter in the history of the Net ASAP.

21 - A web archive containing HTML emails makes searching for
     text a lot more complex.  If there is a plain text part, then
     this may be OK, but what of searching through HTML and missing
     a word because there are bold face tags half-way through it?

     The same argument goes for the perfectly day-to-day business of
     searching a user's own mailboxes.

22 - There is no single reliable way of rendering HTML.  There are
     various flavours of HTML - there are various W3C "standards" and
     various proprietary extensions.  There is certainly no consensus
     on what is kosher HTML and what is not.  Even if there was, then
     in the time it takes for recipient systems to be upgraded, that
     notion of kosher HTML would change, so clients would be getting
     messages from later clients which they would not be equipped to
     handle properly.  The technical facets of the plain text email
     I am advocating have been static for decades (though I don't
     know when the ISO-8859 font was introduced.)  So the spec now
     for "plain-text" is simple and unlikely to change a lot in the

     There are endless possibilities for faulty HTML being generated or
     copied from elsewhere, and for the sender's system to show it one
     way which seems to work, but a buggy or totally standards compliant
     renderer at the recipient's end to fail to cope with the bug, HTML
     standard etc. at all.  For instance MS Front-Page Express
     generates a web page with a line-break in the middle of an address
     for a graphic.  MSIE renders it (with a complaint about errors)
     and any standards compliant browser or cache fails.

23 - An HTML message might look good on the sender's computer but
     fail completely on the recipient's because it depends on graphics
     files, fonts, CSS files etc. which are only resident on the
     sender's system.

24 - An HTML message might appear the way a sender wants it to due
     to the inclusion of Javascript or Java, but the recipient end
     might not render these due to technical incapacity, have it 
     turned off for security reasons, or the method of rendering might
     be quite different from what the sender experienced.

25 - Likewise, the default addition of V-cards and other attachments
     to ordinary emails should be fought against.  The average user
     has no way of knowing what all these attachments may be, and
     may be confused, unsure as to whether it is a virus, may not
     know whether to open it or not, and so may not know whether they
     have fully read the message.  As with HTML emails, the recipient's
     email client may not know how to deal with the attachment anyway.
     Similarly, they clutter mailing list archives and digests.

26 - Plain text emails are almost certainly easier to read and
     respond to (with quoting) for people with disabilities, including
     those who use speech synthesisers.

27 - There is a security problem with Javascript in email - which
     apparently affects Netscape 6, and so presumably originates
     with Mozilla.  It also affects later versions of Outlook and
     Outlook Express:

     The Javascript is carried with the email as people forward it
     with comments to third parties, and each time it is opened, the
     Javascript runs, reads the email (including the added text)
     and sends it back to a server by encoding it into a form response.
         The exploit is made possible because JavaScript is able to
         read text in an e-mail message. If a message is forwarded to
         someone else, the hidden JavaScript code in the page can read
         any text that has been added to the message when it is
         forwarded. This JavaScript code executes when the forwarded
         message is read. The JavaScript code then silently sends off
         this text using a Web bug, or a hidden form, to a Web server
         belonging to the original sender of the message. The sender
         can then retrieve the text and read it.
     This uses a perfectly normal Javascript function - a useful
     sounding feature which no-one thought to consider the security
     implications of before foisting it on the world in the default
     arrangement of the latest and greatest software.

28 - Security problems with cookies . . .

29 - . . . malicious codes somehow related to frames . . .

30 - . . . web bugs . . .

31 - How can you have a consistent signature in HTML without making
     assumptions about the background image or colour of whatever 
     messages you are going to send?

32 - A great deal of email reading and writing is done via web-mail
     systems.  It is a challenge to make a functional system for
     composing and reading plain text (with all the security issues
     of stopping the browser caching the pages etc.) - but to make
     HTML reading is a lot more complication still.  Likewise, the
     complexity (for the user and for the communications and
     programming) in using a Web interface to compose HTML emails.

Other links regarding HTML email security are:

(Note, see the end of this page for more links to pages concerning email.)
I am sure I could think of more - but I shouldn't have to.   What is
wrong with people to think that over-complex, flaky, hard to use and
hard to understand systems are better than simple ones?    Have people
lived such scrambled, TVed, Nintendoed, PlayStationed, caffienated and
conflicted lives that they never developed a gut feeling for the value
of elegance, simplicity and reliability?   Or are the programmers hip
and the marketing people keen for the flaky, zoomy, featuritis bits?  I
hope Mozilla could avoid the negative influence of the latter.

In a nutshell:

  Plain text always works - and HTML doesn't.

  Plain text is easy for anyone to understand - HTML isn't.

  Plain text has a direct, one-to-one, correspondence between what
  characters and placement you see on screen when writing it (assuming
  the compose editor shows how text will be wrapped) and what is in
  fact sent.  There are no layers of nonsense, interpretation etc.

  Plain text always conveys to the recipient exactly what the sender
  wrote (assuming they used a standard character set, not some
  Microsoft abomination which renders quote characters as something
  else on a normal email client).  HTML may convey a message (or no
  message) very different from what the sender thought they were
  sending due to limitations with fonts, bugs in the HTML renderer
  (and there are many flavours of HTML) etc.

 *** So plain text should be the DEFAULT for all email clients! ***

Everyone is sick to death of computery things which look flashy but turn
out to be overcomplex, hard to use, hard to understand, and unreliable. 
It may be that people use computer systems like books in their bookshelf
they have never read  - as a means of conforming to social expectations
and impressing themselves and others.  But a more important function is
to have systems which are easy to use, clear and 100% reliable. 

Since email is arguably the most important function of the Internet, we
should fight to get email client programs right - which means defaulting
to sending plain text, with ISO-8859-1 character set, with fixed width
font, WYSIWYG wrapping to sensible margins (72, for instance).  I think
that, at least in the English-speaking world, these are both necessary
and sufficient to support the great majority of email communication
needs.  Those which are not supported can be achieved by the attachment
of files by users who choose to do so - and these can include HTML

How is it that we can design 30 million transistor CPUs which do
something really rigorous and elegant, but can't decide to use a simple,
clear, long-established technique over something half-baked and full of

Do you want your program to be:

     Flashy and flaky?
     Elegant, easy to use and understand, and 100% reliable?

Its common sense to me.  The world is over-full of flashy, flaky things
- and bad computer software, monstrous web-sites, marketing bumpf,
telemarketing calls, spam etc.  All these contribute to the corrosive,
complicated, entangling and distracting burden we struggle with every

Making all email clients default to plain text with a sensible editor
(as Mozilla seems to have, though it forces all longer than 72 char
URLs to start on the left margin . . . ) is the way to go!

  - Robin

Responding to Ben's first reply

Please refer to the newsgroup for all replies - you are not getting the full debate by reading this page!

     Subject: Re: Plain text vs. HTML email
        Date: Sat, 11 Aug 2001 00:53:28 +1000
        From: Robin Whittle <>

Ben Bucksch wrote:

> > I was asked on this newsgroup (netscape.public.mozilla.mail-news)
> > last year to write about why plain text email should be the default
> > for email clients, rather than HTML.
> [I can't remember that, but it could well be true.]

Perhaps it was a private email from one of the Mozilla editor crew.

> Anyways, I don't know, who you are tring to convince or what you are
> trying to achieve. Plaintext is the default in Mozilla, after long
> fighting.

Wow!!!  I didn't know this.   I am really happy to hear this.  My rant
is redundant.  I apologise for sending it without first doing sufficient

> > 1 -  Plain text is simple and understandable - nothing could be
> >      simpler.  A character is a character.  A newline is a newline.
> Sorry, but that's plain wrong. If you look behind the scenes, that's
> not at all the case.

I meant "understandable" to the user.  People learn to read and write
and the placement of characters on paper is pretty well understood.
What they can't typically foresee is text being rendered in other fonts,
to different margins than they see on their screen, etc.  So if the
indent a paragraph with spaces at the start of the lines they see, this
works fine in plain text and not with something more complex such as
HTML, unless of course the display system has identical right margins.

> > What you type is what you see and what the recipient receives.
> No. Apart from the above, the recipient might choose another font (I
> use a proportional one)

In that case I have no way of getting a message to you with nicely
indented numbered paragraphs or with text-based diagrams.

I think that proportional fonts have important aesthetic advantages -
courier would be sus in a high-fashion magazine (but mandatory in a
grunge fashion mag).

Proportional fonts probably pack more text into a given area for a
certain level of readability, but I think they have their own problems -
particularly on computer screens.  I had an instance of this recently
when a test message from a no-doubt improperly configured mutt client
sent a bodgy email address  That dot after the "@" is
clear as day in a fixed width font, but was hard to notice in the
proportoinal font used in the mailbox display of Netscape 4.x.  In the
font used for the headers in the message display, it really is almost
invisible.   It is only very marginally better under Mozilla.  Two 'l's
can be tricky to read on screen and and two 'v's are often hard to
distinguish from 'w".  "Modern" looks very much like "Modem" etc.

The only functional advantage proportional fonts bring over fixed is an
arguably greater density of characters per horizontal space.  But I
think the benefit is marginal, and very often the text is so closely
packed on a computer screen that readability suffers.

I agree with you that in some circumstances HTML text which was written
with the expectation of an unknown right margin would display better on
a less than 80 character display.

> What is a proper system? Many plaintext messages get munged by broken
> mailers or MTAs.

I can't think of any, but they certainly would be broken!

> > provided sensible right margins are observed in the
> > original message.
> Quotes many times, no reasonable margin will protect from rewrapping
> quotes.

Pegasus mail had a natty feature for re-formatting a block of quoted
within a currently active right margin.  Its tricky, but it can be
programmed - and it is probably a lot easier than the programming behind
graphic emoticons or those vertical bars in place of "> " quote
characters.  That feature disappeared when Pegasus was adapted to try to
work with HTML.

> > 5 -  The messages can be displayed with minimal fuss on mobile
> >      devices and text consoles with no graphics capabilities and
> >      small screen sizes.
> That's just so wrong.

In some cases, HTML text would be easier, I agree.  But a character cell
display can't do bold-face or italics or different sizes or colours - so
if the message was written in HTML with the sender thinking that the
recipient would see all this, then there's no obvious way of conveying
it on the non-graphic display - or even the fact that the communicated
information is missing. 

With plain text, you are relying purely on symbols which are carried
without degradation to any conceivable visual display device, so you use
asterisks for *bold* etc. to convey things and you know that cannot be
stripped out by any technology at all . . . . unless something comes
along and replaces a colon and a bracket with an emoticon, or starts
bolding things you never meant to be bold.

Anyway - I apologise for launching this rant here.  I understand it is
entirely redundant and I am really happy about this!

I checked back in this newsgroup a month, not since late last year - and
my Mozilla install used my Netscape preferences, so I didn't notice that
plain text email was the default.

 - Robin

Responding to Ben's second reply

Be sure to see the newsgroup for Ben's response to this!  We agree on some things and not on others.

    Subject: Re: Plain text vs. HTML email
       Date: Sat, 11 Aug 2001 17:54:52 +1000
       From: Robin Whittle <>

I am continuing this discussion on the assumption that while not
everyone thinks raw Mozilla (at present) is for end users, that Mozilla
should in its default state be configured to meet the real communication
needs of the majority of end users, especially those who have no
technical inclination at all and are unlikely to be aware of how they
might change the program's configuration.

Ben Bucksch wrote:
> Robin Whittle wrote:
> > Plaintext is the default in Mozilla, after long fighting.
> > Wow!!!  I didn't know this.   I am really happy to hear this.  My
> > rant is redundant.  I apologise for sending it without first doing
> > sufficient research.
> >
> [...]
> > my Mozilla install used my Netscape preferences, so I didn't notice
> > that plain text email was the default.
> Just so you don't misunderstand me: Mozilla *sends* plaintext by
> default, but the default *composer* is HTML. We convert to plaintext
> during sending. Sometimes, we ask the user, but with plaintext
> preselected.

Hmmmm.  I had assumed you meant that Mozilla defaults to the plain-text
message composer and sends plain text messages.

I did a fresh install without copying details from a Netscape profile.

I composed a message and it is the HTML composer - with toolbar options
for headings, fonts, colours, text sizes etc.  I wrote a test message
using all these.

When I pressed the Send button, a dialogue box appeared saying:

    Some of the recipients are not listed as being able to receive
    HTML mail.

    However, you used formatting (e.g. colors) that will not be
    converted to plain text.

    Would you like to convert the message to plain text or send it
    in HTML anyway?

       O  Send in Plain Text and HTML
       X  Send in Plain Text only
       O  Send in HTML only.

Before I sent this test message, here are my comments on the situation
so far.

It is reasonable to assume that many users have no idea what "HTML"
means.  (I run a busy mailing list on a non-technical matter and I know
from list members that they have not a clue about computery things and
have very little interest in changing this - as long as they can get

They start composing a message, typically with the Recipient's name
already entered, and the program lets them go to town with HTML.  Via
the menus, it is possible to do the whole thing - background images,
graphic files, tables etc.   Then, when it is time to send, the program
tells them that perhaps the Recipient won't be able to see all the
things they just composed.

Also, is it really kosher to send only HTML in emails?  I suppose if you
know the other person wants it - but it would make a mess of mailing
lists and confuse many recipients not to have a plain text version. 

Here is a suggested rewrite of the dialogue box - to help people who do
not understand what HTML is.

    Your email used formatting, such as colors, font settings and
    headings which can only be sent using HTML. 

    Some recipients cannot view HTML emails - and one or more of the
    recipients of this message is not listed as being able to
    receive HTML email.

    Would you like to convert the message to plain text or send it
    in HTML anyway?

       O  Send in Plain Text and HTML
             All recipients will be able to read your message - but
             only those who can read HTML messages will see your

       X  Send in Plain Text only
             All recipients will receive your text without formatting.

       O  Send in HTML only.
             Recipients who cannot view HTML email will not be able
             to read your message.

Its longer, but email is the most important function of the Net, I think
so it is worth lots of trouble to get it right.  Because it is a
unidirectional thing, and because you may never hear from the recipient
if they can't read your message, it is vital that messages be sent in a
form they can be read.

I mow understand what you wrote earlier.  Mozilla uses the HTML composer
and then converts to plain text.

The message came through as plain text with the following changes:

1 - The Heading 2 was indented by three.

2 - The word "italics" I had italicised was sent as:

    Similarly: *bold* and _underlined_.  But there was no special
    handling of strikethrough.

    Bold and italics was handled:   */blah/*

3 - In Mozilla's sent mail folder (at first it took it a while to
    save it in my correctly specified IMAP folder, but it did work -
    this is on Windows 98) the message is saved at plain text, but
    is displayed with anything between asterisks as being bold and
    anything between /.../ as italics.  */blah/* displays normally.

4 - A table is sent with each cell as a separate line or lines.

> I believe that this is the best solution, considering that many, many
> non-computer-savvy users, which hopefully end up using Mozilla. They
> don't care about character-level control, but want a nice GUI which
> does the work for them. If we present them with a plaintext editor,
> their reaction will be "Uh, ugly! Where was the Microsoft one again?".
> We give them that nice GUi and a nice output, while maintaining
> compatibility even with the oldest mailers.

I don't agree at all with your characterisation of many or most
non-computer-savvy users being hostile to a plain text editor, and
demanding one with features and propotional-spaced fonts. 

I just got a fresh HotMail account and it composes in fixed width plain
text, wraps on the screen to 70 columns (which can't be changed) exactly
as it is going to send in the message (except that long URLS are not
wrapped in the final output, and an attempt to indent them fails on
screen and in the final message) and generally does what I am advocating
being the default for Mozilla.  It displays ordinary plain text messages
in fixed width fonts too.   HotMail seems generally sensible.  My two
gripes are that it sends with "format=flowed" (RFC2646) and quoting is
done with ">" rather than "> ".  I think the latter is best to preserve
the words as separate entities, for the purpose of reading and

But for the purposes of this debate I wall accept what you say about
non-computer-savvy users.

I remain adamant that the mail system which best suits their needs - and
the needs of all people except those who actually understand HTML and
are sure that their recipient wants HTML emails - is a plain text editor
like Mozilla now has, with fixed width fonts, WYSIWYG wrapping to a ~72
margin, no emoticon or bold/italic pretty printing and straightforward
display of *all* characters, without vertical lines in place of "> "

Just because of some ugly combination of:

1 - Some or many people being easily impressed by feauritis-infested
    computer programs (and despite other people finding them
    intimidating, and preferring WebTV!).

2 - A company called Microsoft happened to land in the natural
    monopoly position.

3 - The natural monopolist chose to encrust its programs with
    immediately obvious, flashy, flaky "features" such as make the
    standard configuration of Word such a nightmare of things
    automatically taking actions which perhaps you wanted, but would
    generally prefer to do explicitly.

doesn't mean that it is doing a service to people to indulge their most
obvious and inexperienced desire.   If someone bounds into a sports
store and wants to buy sneakers with energy-returning radon-inflated
heel buffers, are you doing them a service by selling them what they
initially think they want or telling them that you believe that such
sneakers are a health hazard, and the ones which really improve
performance are the ones you stock?

Even if there are a bunch of people who want computer programs to make
them feel good by being be-jewelled with pseudo-sophisticated and
colourful "features", why should Mozilla degrade and complexify the
email communications of the great majority of its users just to
initially impress people who are initially impressed by dingly-dangly

(An answer could be found in my most depressing thesis, which I won't
elaborate - a broad and condemnatory generalisation which I am
constantly trying to tell myself is not as true as sometimes I fear -
that "people like shit".  That's on a bad day.  Most of the time, most
of the people I know, want straightforward clear functional things - at
least in the computer/Internet parts of their lives.)

> > I get frustrated at times that so much effort goes into making
> > things that look impressive at first, but in fact lack depth and
> > reliability - and are then presented to everyone as the default way
> > of doing things. The result is a ***lot*** of frustration, wasted
> > time and effort and miscommunication.
> While I agree that plaintext should be the default, it is ironically
> this very decision of Netscape to push HTML, that probably saves us
> from worse problems. If it were not for Netscape estabilishing HTML, I
> bet that Microsoft's mailers would send RTF by default by now.
> Someday, you might have needed Microsoft Word then to read mail from
> clueless MS users.

Yes, I am sure that the evil empire would have tried to do this.

But none of this justifies Mozilla or any general usage email client
being presenting with default settings so that it is anything but 100%
reliable and easy to understand.  As far as I can see, my plain text
proposal is the only one which meets this requirement.  The popularity
of HotMail and other web-based email services which are, as far as I
know, almost always based on plain text, fixed width fonts, WYSIWYG
on-screen wrapping to sensible margins (actually, some violate this and
send paragraphs as a single line) would seem to disprove your idea that
Mozilla must pander to people who want something flashier.

This is not a case of plain text being old and HTML being new and all we
need to do is get everyone HTML-capable.  There are fundamental reasons
why people want to be able to communicate with straightforward symbols
arranged in a way that no intervening process will alter them.

Mozilla's current default of writing in HTML and sending in plain text
only resolves some security problems I mentioned for HTML.  It still
means that the writer has no clear idea of how their text will be laid
out to the recipient - until after it is sent, and even then, Mozilla
(when displaying received or sent mail) puts in bolding and italics
which do not exist in the message itself.  (Also I guess it puts in
emoticons and those damn vertical lines too.)

I won't report here on the flakiness I see in the HTML composer, except
this one, to give an example.

- - -

I type:

1 - This is an example of trying to indent a paragraph. blah blah

When I did the "blah " with pasting, it got to the end of the line and
then put the entire "blah blah . . . blah" sequence on the next line!
Typing it in wrapped the text as one would expect.

- - -

Using the Mozilla default arrangement, the inexperienced user can quite
naturally and innocently construct an indented numbered paragraph which
looks fine on screen and which they expect the recipient to see
verbatim.  But of course, due to the hidden complexities of HTML, the
message is not really indented as far as the program is concerned, and
when it is sent it has lots of multi-space gaps - whether it is sent as
plain text, or indeed as HTML and viewed with another window width.  The
result to the recipient is:

- - -

1 - This is an example of trying to indent a paragraph. blah blah blah
blah blah blah blah
      blah blah blah blah blah blah blah blah blah blah blah blah blah
blah blah blah blah
This is the next line.

- - -

So the current Mozilla arrangement puts ordinary users straight into a
situation where their attempts to communicate are likely to be
frustrated by the plain text conversion or by the problems I listed
earlier with HTML email even when it is read by an HTML compatible

I re-instate my rant!

  - Robin

To be continued!

Links regarding email and this debate

Using Internet mail by Greg Lehey Various formatting and email client problems and how to avoid them.

The Internet Mail Consortium

The master list of Internet Standards and where to get RFCs