Problems with HTML email
This page contains some arguments as to
There are also some links to relevant pages.
- HTML email is often more trouble than it is worth.
- 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.
Robin Whittle firstname.lastname@example.org Last update 17 August 2001.
to the sys-admin page for more computery things.
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: http://www.mozilla.org/
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 http://www.mozilla.org/MPL/
and more info on open-source software can be found at http://www.fsf.org/
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
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 news.mozilla.org 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://news.mozilla.org/netscape.public.mozilla.builds
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 http://sunsite.anu.edu.au/link/
and the August 2001 archives are here: http://www.anu.edu.au/mail-archives/link/link0108/
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 <email@example.com>
To the Mozilla developers, the Link mailing list and other people who
might be interested.
I will soon add this to: http://www.firstpr.com.au/sys-admin/HTML-mail/
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
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
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
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
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
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
24 - An HTML message might appear the way a sender wants it to due
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.
apparently affects Netscape 6, and so presumably originates
with Mozilla. It also affects later versions of Outlook and
with comments to third parties, and each time it is opened, the
and sends it back to a server by encoding it into a form response.
read text in an e-mail message. If a message is forwarded to
any text that has been added to the message when it is
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.
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!
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 <firstname.lastname@example.org>
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
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 blah@.example.org. 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
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.
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 <email@example.com>
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
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
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
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
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
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.
- - -
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!
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