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:
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!
>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.]
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.
>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. A message is a stream of bits.
We chose to arrange these bits in bytes, but that limits the characters
to 256. This means that many languages cannot be represented there, and
even the upper 128 of these 256 are not universially defined. If you
left the english language room, you sure saw odd characters instead of
umlauts or similar.
Also, all 3 major platforms - Windows, Mac and Unix - disagree on what a
> 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) or wrap at different places (e.g. PDAs don't have 80
chars wide displays).
> are no ways, in a proper system, for things changing or being
What is a proper system? Many plaintext messages get munged by broken
mailers or MTAs.
>provided sensible right margins are observed in the
> original message.
Quotes many times, no reasonable margin will protect from rewrapping quotes.
>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.
>7 - Plain text is easy to read,
No. It goes contrary to common reading habits, which are proportional
fonts. Also, the reader being able to choose the width of the text
[much cutted - no time atm]
> > 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.
>>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
>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.
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.
Robin Whittle wrote before:
>>>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.
> Robin Whittle wrote:
>> There are no ways, in a proper system, for things changing or
>> being obscured,
> What is a proper system? Many plaintext messages get munged by
> broken mailers or MTAs.
Ah, you mean OE? http://www.lemis.com/email/fixing-outlook.html
Robin: You may be interested in adding http://www.lemis.com/email.html
to your document. It is a very well written article about e-mail (and
it's by a fellow countryman of yours - assuming you are a native of .au
- Greg Lehey). The Microsoft Outlook link in the section "Which mailer
should you use?" takes you to the "fixing-outlook" link above.
And yet just yesterday you said, in a rather forceful post about spell
> Mozilla is not made for end-users
>> I believe that this is the best solution, considering that many, many
>> non-computer-savvy users, which hopefully end up using Mozilla. They
> And yet just yesterday you said, in a rather forceful post about spell
>> Mozilla is not made for end-users
Yes. With "end up", I meant that they use derivates of Mozilla, which
includes Netscape 6. (Unfortunately, Netscape chose to differ from
Mozilla about the default send format in one case, but we can't stop
them.) Mozilla *itself* is not for end-users.
Most people "ending up" using Mozilla use Netscape 6, which does have a
spell-checker. Surely, an open-source spellchecker would be better,
because all would have it. But we're not there yet.
How the Netscape spellchecker can be used with Mozilla is irrelevant for
the development of Mozilla. People which seriously want to test Mozilla
have to deal with harder problems than a missing spellchecker or how to
install a given one.
What I was saying in the second quote was simply that this is not a
forum for end-users. We are here to discuss development of Mozilla. If
some of the developers chooses to implement the spell-checker (either
because he wants to or because *his* users asked him to), then fine, and
we can discuss how to do that. But asking for a spell-checker here will
do absolutely nothing other than annoy many people, because we have seen
this request numerous times already.
In short, this whole recent spellchecker discussion did nothing for the
development of Mozilla. It just cluttered up this newsgroup.
(I'm writing all this in the hope that it will stop these offtopic
discussions. But who am I fooling?)
Complaining ("Why hasn't this been implemented earlier? This is an
absolute necessarity") or user help ("How can I do use xy?") is not
placed right here. It is acceptable, if it happens once in a while and
is new. But is it not acceptable that the same questions and opinions
come up again and again. We expect that you searched the archive of this
group before you post. If you post a question that has been answered
just a week ago, expect hostile reactions. That's what happened here.
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!
>I am continuing this discussion on the assumption that while not
>everyone thinks raw Mozilla [...] 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.
>I did a fresh install without copying details from a Netscape profile.
You don't need to do a fresh install. Just create a new profile using
Mozilla (and use it in Mozila only then).
> 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.
Note that there are 3(!) versions of this dialog, depending on how much
formatting you use. Try with bullet lists only, then with bold, then
>It is reasonable to assume that many users have no idea what "HTML"
I am aware of that. Before Netscape 6.0, I tried to get a Help button
in, but it was rejected, because Mozilla didn't really support help
buttons at that time. Now it does, but I somewhat lost interest. I might
jump in, if somebody goes to tackle this.
>Here is a suggested rewrite of the dialogue box - to help people who do
>not understand what HTML is.
There is a bug about changing the wording of this dialog. Read it. If
you think, you have a better suggestion than those there, feel free to
>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.
The problem is that:
* The recipients can be entered/changed at any time
* We shouldn't change the UI while the user types recipients
* Even if we don't know that the recipient can read HTML, he might
be able to (in many cases, he is and doesn't object)
It is right that the user probably won't know even less, if the
recipient can read HTML. There is a proposal about a UA-sniffer and
special a message header, so we determine ourselves, what the recipient
wants. But it's some work, which I wasn't willing to put in yet.
Yes, and this is, IMO, a problem, considering how often that dialog
>it is vital that messages be sent in a form they can be read.
>I just got a fresh HotMail account
Hotmail doesn't count - it is webmail. To my knowledge, there is no
save, interoperable way to compose HTML in webpages.
>1 - Some or many people being easily impressed by feauritis-infested
> computer programs (and despite other people finding them
> intimidating, and preferring WebTV!).
It is not about impressing people.
If you give people plaintext editor, I am sure, they wouldn't know how
to stress words, other than maybe by falling back to type writer machine
habits and doing _underline_.
Similarily, I am very sure that most people would consider it be a pain
to have to write bulleted lists with a plaintext editor only.
Sure, you can support that by indenting new lines as much as previous
ones, but what do I do after the bullet? Also, I know that back in the
DOS days, there were people religously fighting against auto-indent just
like people are fighting about Mozilla's defaults today. Also, what
happens when a user inserts a word in the first line of a 3-line
bulleted and indented item? Will the editor rewrap? Will the following
lines be rewritting to keep the same indention? How many people will
object that "fancy featurism" which "does things they didn't tell it to"?
Writing good plaintext mails needs to be learned and then still needs
some dedication to get each instance right. As you pointed out, most
users are unwilling to invest that time.
The HTML composer lets them quickly compose what they want and the
converter will then make it look right in plaintext. IMO, a "no-worry
solution" for end-users. (Assuming they don't have to answer that
>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.
(Note: It's not only MS. It was Netscape which invented HTML mails, and
Eudora and Lotus Notes (the latter being very big in corporations) use
rich formatting editor by default, too. I'm not presenting this as an
argument, just as a matter of fact.)
>doesn't mean that it is doing a service to people to indulge their most
>obvious and inexperienced desire.
Agreed. But I do think that wour solution is best. (OK, if maybe we
remove Fonts and Colors in the Composer.)
>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.)
Just that is it not yet clear what "shit" and what "straighforward" and
"functional" is. From the user's point of view, who spends his day and
talking on the phone and writing documents in MS Word, an icon for a
bulleted list is straightforward and functional. Not having that would
be seriously underpowered for him.
>[webmail] would seem to disprove your idea that
>Mozilla must pander to people who want something flashier.
I think that hardly anybody who uses email regularily uses webmail.
If you are new to email and just write a few paragraphs of text, telling
that you are fine and asking how the other one is and telling that your
neighbor married recently, you don't need bulleted lists. But, if you do
only that, the HTML composer will work just fine for you. It will
convert to plaintext without even asking and the result will look
exactly like the text you wrote. (In Mozilla at least. In other mailers,
the lines will wrap at different places, but if you write only linear
text, you don't care.)
If you use email more, then once in a while, you will want to compose a
longer text with more sophisticated formatting, like bulleted lists and
emphasis. Mozilla will convert to plaintext (with asking you), but the
result will look very close to what you wrote with the GUI.
If you want to try your email program's features and write a flashy
email with colors and big text and much formatting and stuff, then
Mozilla will (at the end, which is admittably a bit late) tell you that
the recipient might not be able to read it. You will learn not to use
flashy formatting in mail.
If you want to cerate ascii-art, you are most likely an advanced
computer user, and you know how to get to your favourite plaintext composer.
>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.
Actually, plaintext does get old, very old. (Normal) Plaintext can't
deal with any languages other than English very well, it can't mark
quotes unambigously, it can't be displayed well on devices with small
displays and structure (like bulleted lists) are emulalted via text,
which cannot be reliably understood by computers (which is a
disadvantage, if you want to create summaries automatically or get a
high-quality print or rewrap or anything).
HTML, when used well, is superiour to plaintext in all aspects, but one:
backward-compatibility. That's the reason why Mozilla sends it by
default at the moment.
But I do believe that in the long run, HTML is the way better choice.
Given that, I think the best thing to do is to use HTML when possible
and fall back to plaintext, when we are not sure. That's exactly what
>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.
Which reasons? The following one?
[Using using autop-wrap together with manual indention]
>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
I assume that the user knows a word processor. Almost everybody who got
a computer at work had to complete some MS Word course, at least here in
In word processors, you can't go and indent lines with spaces either.
The people that do are former type writer users and they are habituated
to hit enter at the end of the line. In that case, it will look
approximately right, no matter, if we send as HTML or plaintext. That is
assuming that the recipient has the same window width, an assumption the
user (!) wrongly made and an assumption that plaintext unfortunately
forces us to.
Are you SURE about that? REALLY sure?
(*Asterisks* and _underlines_ might be a hacker eccentricity, but
capital letters sure ain't.)
> Similarily, I am very sure that most people would consider it be a
> pain to have to write bulleted lists with a plaintext editor only.
Only obsessive typographers such as myself would worry about trying to
indent successive lines in the list. Most would be quite happy just
putting a number or asterisk at the start of each paragraph, with no
indention of later lines.
> > doesn't mean that it is doing a service to people to indulge their
> > most obvious and inexperienced desire.
> Agreed. But I do think that wour solution is best. (OK, if maybe we
> remove Fonts and Colors in the Composer.)
Judging by my watching of those Hotmail and Yahoo Mail users who turn on
the `Rich text' option, and by the HTML messages I receive myself, fonts
and colors are the only things HTML message authors are interested in at
all. (Bulleted lists, tables, etc are offered in the HTML toolbar, but
I've *never* seen people use them, or received messages that contain
them -- other than those in the netscape.public.mozilla* hierarchy itself.)
So, removing fonts and colors from the HTML message composer would be a
sure-fire way of removing all the attraction the feature has for users,
while retaining all the aggravation it causes. Which would be a neat
trick if your long-term plan was to make plain text composition the
default, but you appear not to want that.
> > [webmail] would seem to disprove your idea that
> > Mozilla must pander to people who want something flashier.
> I think that hardly anybody who uses email regularily uses webmail.
Only rarely do our customers do anything else but use Webmail. We have
thousands of customers per day. Hotmail has about 90 million accounts
(though perhaps a couple of million of those are spam accounts). Yahoo
Mail is in the tens of millions too.
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
With an alert that long (it's an alert, not a dialog, because it's an
interruption rather than an intended part of the user's task), perhaps 5
percent of people will be bothered reading it at all.
As for the other 95 percent, which button they press will depend on
their personality. Either they'll blindly click `OK' without reading the
message (on the assumption that the computer knows what's best), or
they'll blindly click `Cancel' without reading the message (on the
assumption that any alert that large must be something bad), whereupon
they'll wonder why the message hasn't been sent.
Or, if they happen to be at an Internet cafe, they'll #@$%! come and ask
me for help.
With the current alert, perhaps 30 percent of people will be bothered
reading it. Making it any longer would be hopeless. To add insult to
injury, the current alert uses radio buttons where it should use push
buttons (wasting mouse clicks), and it uses an icon (the question mark
icon) which should not exist in Mozilla at all.
> 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.
True. I tend to delete HTML mail unread -- partly out of annoyance with
the sender's waste of my bandwidth, partly because HTML-ness is a very
good predictor of spam-ness, and partly because it's usually in a
too-small font. (In 4.x about a dozen key-presses are required to zoom
the text to a reasonable size, and Seamonkey lacks the ability to do it
> I mow understand what you wrote earlier. Mozilla uses the HTML
> composer and then converts to plain text.
Perhaps the worst of all possible worlds. :-] Neither the sender *nor*
the recipient sees what is intended.
> I just got a fresh HotMail account and it composes in fixed width
> plain text,
Unless you're using MS Internet Explorer 5.0 or later for Windows, you
obviously have no option *but* to use plain text. A good HTML editor
embeddable in a Web page would be a huge (I hesitate to use the word
`revolutionary') feature for blogging and Web authoring purposes (even
ignoring its potential use for Webmail), but the various people
interested in implementing it in Mozilla (see occasional posts in
n.p.m.editor) don't seem to have been able to get any traction with the
As for the fixed-width-ness of the textarea, that generally depends on
> (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.)
Microsoft software is very popular, and this is only partly because of
abuse of their effective OS monopoly. Microsoft knows that even
poorly-implemented features sell better than security, reliability, or
interoperability do. (In a nutshell, this is because humans are
pathologically bad at handling low-probability high-damage risks, such
as those of e-mail viruses; debates over the merits of nuclear power and
weaponry are the most extreme example of the same problem.) Usenet
regulars and Linux/Unix users, who typically have a different set of
priorities, regularly rant and fume (or, in your case, depressedly
thesisize) about the rest of humanity as a result.
> Ben Bucksch wrote:
>> If you give people plaintext editor, I am sure, they wouldn't know how
>> to stress words
> Are you SURE about that? REALLY sure?
OK. Humans know how to yell. I should have known ;-P-
> Only obsessive typographers such as myself would worry about trying to
> indent successive lines in the list. Most would be quite happy just
> putting a number or asterisk at the start of each paragraph, with no
> indention of later lines.
With the associated degration of readability.
(If you want to do that, nobody stops you - it will work just fine in
the HTML editor.)
> So, removing fonts and colors from the HTML message composer would be a
> sure-fire way of removing all the attraction the feature has for users,
> while retaining all the aggravation it causes. Which would be a neat
> trick if your long-term plan was to make plain text composition the
> default, but you appear not to want that.
>> I think that hardly anybody who uses email regularily uses webmail.
> Only rarely do our customers do anything else but use Webmail. We have
> thousands of customers per day.
You are at an internet cafe, right?
1. Internet cafes are usually frequented by people who don't have their
own internet access <-> use the internet rarely.
2. Given the current dedicated Mailnews clients and their "preferences"
storage (which you rightfully critized in earlier posts), webmail is the
"only right thing" to do at an internet cafe.
> Hotmail has about 90 million accounts
> (though perhaps a couple of million of those are spam accounts). Yahoo
> Mail is in the tens of millions too.
And there are a lot of internet mail newbies. What's your point?
I use Yahoo! Mail [on the web] as my main e-mail account. I've had this
Y! account since '97, and I don't consider myself a newbie. Even during
the [short] period when I used Outlook Express as my mail editor, I
changed everything to be plain-text only, just as I did with Mozilla.
After many years of using PINE as my mail editor at college, I find that
HTML mail is only used for SPAM, and by the unsuspecting luser.
I've seen Rich Text mail editors online [mad Java though...]. They would
be great, except for the fact that I think e-mail should be plain text.
All Internet ettiquette explicitly states that e-mail should be to the
point, and not need inflection to make it's point, as subtleties don't
traverse the 'Net well. So, italics, boldness, and underlining should be
superfluous. On the rare occasion something needs extra intensity,
simple CAPS should do. Plain text should be default - and should be the
Just my thoughts,
Brian Z Jones | down8 at yahoo dot com
Mozilla 0.9.3 | Windows 2000 Server, SP2
There is a MIME type for rich text. Unfortunately, that's not what
LookOut uses when a user asks to format a message in rich text: it sends
plain text plus an attachment file with formatting instructions. A
recipient not using an M$ product doesn't see any of the formatting.
This is essentially the same problem Robin has complained about in
Mozilla: sent messages not looking as he wrote them, and with no notice
to the sender.
Personally, I also prefer plain text. But I have no objection to rich
text in the MIME format. It isn't hard to read with a plain text agent.
Dave Close +1 949 260 0418 x555
StrataSource Inc dcl...@stratasource.com
Irvine California http://www.stratasource.com/
Somebody was talking about international characters. Well my native
language is not English, so I use non-English characters all the time.
There is no incompatibility between plain text and international
character sets. Your recipient is supposed to know in which language you
are sending the email anyway. if they are not, they probably doesn't
have the corresponding fonts mostly and it really doesn't matter. HTML
has more problems.
I always use plain text and I hate people sending html email. The only
ones I receive html mail are spammers. The rest of the html mail I
receive is actually plain text but sent as HTML. This is mostly done by
hotmail since IE+hotmail always default to html sending with no plain
text part. Try to read those emails with pine???
> This is essentially the same problem Robin has complained about in
> Mozilla: sent messages not looking as he wrote them, and with no
> notice to the sender.
FYI: There *is* a notice to the sender on Mozilla. If we convert to
plaintext and it will look different, we pop up a dialog.
> if they are not, they probably doesn't have the corresponding fonts
> mostly and it really doesn't matter.
I myself hear reports about umlauts being converted to "?" or similar
garbage all the time. MS OE seems to be particularily bad about it.
And certainly it does matter. 8r donÄt you tzinkÜ tzat tzis is not very
readable and tzat users will botzer about it# (That's how badly
converted German plaintext looks like when you read it.)
> I hate people sending html email. [...] Try to read those emails with
No objection from me here.
I think that the people in those cafes are very those who have their own
computers at home or in the office - but they are at lunch, on holidays,
doing something they can't do at work etc.
Email is where so much energy goes for many users. Their communication
needs are not complex, as far as I know - it is generally words with
paragraph layout, quoting of material from the message being replied to,
often some URLS and sometimes sending and receiving attachments.
Most people have no understanding of HTML and different formats, or how
things they do on screen won't appear to the recipient, will appear in a
garbled form, and/or will annoy the recipient (especially if it goes to
a mailing list) - so I believe Mozilla should default to plain text
compose so everything they write will in fact get through without loss,
mangling or complications.
You also seem to assume that the elusive "average user" or newbie knows
how to operate a word processor.
I don't assume this at all. I assume they know how to read and write.
I assume they want to use the alphanumeric symbols, in order, and have
them arrive in that order and with the same layout, or at least a layout
that doesn't alter what they are trying to achieve. The probably don't
want to learn any commands, configuration options etc. and I am sure
they don't want to be faced with any dialogue box which urges them to
send their message in a way which strips out some of the things they
might have done to it and (although they probably don't realise it at
the time) will completely reformat the lines they saw into different
lines in the final plain text output.
Even those who use Word every day may be utterly clueless about it. I
once got a draft paper from a psych professor, who wrote a voluminous
book with over a thousand references. I think he had the footnote bit
sorted out, but all his headings were manual boldface. So here is a
published author who has spent years using Word professionally, and he
doesn't know what a style is.
While some people want to press buttons and have fun with colour and
fonts, I think most people just want to get on with using things without
having to discover anything extra about the tools they are using.
But these are peripheral arguments to my main ones:
Plain text meets the requirement that a unidirectional communication
system should not transform what the sender thought they were sending
into something else. Even with HTML email clients at both ends, there
are so many variables such as fonts, bugs in the HTML which the sender
tolerates and the recipient client refuses to handle etc., that there is
no certainty of reliable communications now or in the foreseeable future
with HTML. There will never be a situation in which all email clients
are HTML compatible - so I think it is best to make the default for
clients plain text and let their HTML functions be used on an opt-in
basis by those inclined to do so.
I imagine that Matthew Thomas or any other Net cafe operator could give
a more reliable report on the email needs of the majority of Net users
than I can. My impressions are largely drawn from emailing privately
and with a busy mailing list with hundreds of people who are keen to
write and who have no particular interest in computers at all - because
the list has nothing to do with computers.
That is a missing font problem and no, MS OE is actually the best if you
have the proper font sets installed from Windows update. Netscape has
problems once in a while. The problems are bigger in Linux and
especially with Konqueror.
Basically what happens is that in one common font family such as Times
New Roman, you usally have all the international characters of that font
installed. So plain text users are happy. The problem begins when
somebody sends an HTML email in Comic Sans MS font with umlauts and
stuff, the other guy is screwed 99% of the time.
Of our regulars (i.e. customers other than tourists), I'd estimate the
average frequency of visit is two or three times a week. The median
session length would be about 20 or 30 minutes. Not *that* different
from Grandma checking her e-mail on her iMac.
> 2. Given the current dedicated Mailnews clients and their
> "preferences" storage (which you rightfully critized in earlier
> posts), webmail is the "only right thing" to do at an internet cafe.
True. (I notice you didn't bother indenting successive lines in your
> > Hotmail has about 90 million accounts
> > (though perhaps a couple of million of those are spam accounts).
> > Yahoo Mail is in the tens of millions too.
> And there are a lot of internet mail newbies. What's your point?
A considerable proportion of Webmail users have been using the Internet
for years, and would find the `newbie' tag mildly offensive as well as
inaccurate. And increased experience isn't goint to magically make such
users start to want bulleted lists or variable indentation levels.
>Not *that* different from Grandma checking her e-mail on her iMac.
Right. But Mozilla is not only for Grandma. Sure, it should be usable by
Grandma. But we have lots of users who spend 2 hours a day with this
I believe that
* Grandma won't even notice the difference between the HTML or
plaintext composer, apart from the other font.
* There is a large number of users, who spent a lot of time with
email and who want features like bulleted lists and indention.
* These users do not change preferences to get to the composer they
want, because they have a problem with current prefs dialogs.
* There are users who prefer the plaintext composer, e.g. for
ascii-art or just because or long-grown habits, but they do know
how to switich to the plaintext composer.
>(I notice you didn't bother indenting successive lines in your
Yes, I noticed that after I sent it, too :-). I would have bothered, if
the list was longer or the items were longer.
>And increased experience isn't goint to magically make such
>users start to want bulleted lists or variable indentation levels.
But can we agree that there are enough users that want this?
No critisation to the ideas in your email, but...
I think the preferences are customizable in mozilla.
So whoever wants html email, they can select it. The discussion was about what to make default.
Does the dialog show how the converted text will look? I didn't think so.
> Does the dialog show how the converted text will look?
That was an idea once and it is indeed possible, but we pushed it out to
a later date.
I think it should be a checkbox in the composition window itself -- as
it is in Hotmail and Yahoo Mail -- which the user needs to turn on in
order to see the formatting toolbar. (Of course, we should clean up the
dreadfulness of the current prefs UI too.)
> > And increased experience isn't goint to magically make such
> > users start to want bulleted lists or variable indentation levels.
> But can we agree that there are enough users that want this?
Not enough to warrant constantly putting up an alert about converting it
into plain text, no.
Here's some food for thought: As time goes on, the number of
confirmation alerts which are part of the design for any GUI application
should approach zero.
>I think it should be a checkbox in the composition window itself -- as
>it is in Hotmail and Yahoo Mail -- which the user needs to turn on in
>order to see the formatting toolbar. (Of course, we should clean up the
>dreadfulness of the current prefs UI too.)
Yes, I agree.
Hiding the formatting toolbar is no problem, actually that works already.
Changing from HTML to plaintext composition rules is more difficult. But
should be possible nevertheless, with the necessary amount of work. Just
that nobodoy volunteered.
>>>bulleted lists or variable indentation levels.
>>But can we agree that there are enough users that want this?
>Not enough to warrant constantly putting up an alert about converting it
>into plain text, no.
Yes, I agree that the dialog should appear much less often. There are
ideas about that, too, e.g. content-negotiation / UA-sniffing (bug 27933).