This is a new beginning for a page
which I created in 2001 and had not updated by September 2015, entitled
"Problems with HTML Email".
That page appears below, unaltered, as an historical document.
Most of it is still true - HTML emails have numerous problems.
However, it seems that I and everyone else needs to send them now,
since many people are using email clients which cannot properly display
or reply to plain text emails.
A plain text email involves lines typically limited to some readable
width, such as 72 or 80, with exceptions for long URLs. The
spaces and line endings of what the user saw when they composed the
message are sent verbatim, and should be displayed in the same
way. As long as the sender composes with a fixed width font, and
the display uses a fixed width font, the recipient sees exactly the
same text and formatting as what the sender composed, with the
exception that most receiving clients automatically find a word
starting with
http:// and display it as a clickable hyperlink.
This made it possible to simply paste a URL into a message, and the
recipient would automatically find this to be a clickable link.
There is no colour, bold-face etc. (though some recipient clients annoyingly displayed
*xyz* as bold
xyz). Some recipient clients, by default, replaced emoticon text elements such as "
:)"
into a smilie graphic, which I think detracts from the minimal
ASCII-art charm of the plain characters, and involves arbitrary
aesthetic choices invisible to the sender and recipient, and typically
beyond the control of both.
It also enabled complete communicative freedom regarding formatting, such as arbitrarily complex tables, indentation etc.:
Selahammahlekoth, Chushanrishathaim and Mahershalalhashbaz
are long names from the Bible. Amy, Ava, Ben, Sam and Max
are shorter names not found in the Bible. Blah blah blah
blah blah blah blah blah blah blah blah. The limitations
on this principle are the behaviour of:
1 - Huey.
2 - Duey, except on on Sundays.
3 - Louie, whose behaviour depends on the phase of the
moon, the price of eggs, how many angels are found,
by careful experiment to be capable of dancing on
the head of a pin and several as-yet undetermined
factors.
However, many email clients (and users are typically unaware of what is
happening, and unwilling or unable to choose a better client, or
configure it to behave better) display such a message in a proportional
width font, which screws up the formatting of indents, any kind of
tabular layout etc:
Selahammahlekoth, Chushanrishathaim and Mahershalalhashbaz
are long names from the Bible. Amy, Ava, Ben, Sam and Max
are shorter names not found in the Bible. Blah blah blah
blah blah blah blah blah blah blah blah. The limitations
on this principle are the behaviour of:
1 - Huey.
2 - Duey, except on on Sundays.
3 - Louie, whose behaviour depends on the phase of the
moon, the price of eggs, how many angels are found,
by careful experiment to be capable of dancing on
the head of a pin and several as-yet undetermined
factors.
I think many of these clients use a sans-serif font, so there is no
visible difference between upper-case I and lower case L. These
stylish fonts, when rendered in a small size, are difficult to read for
people with astigmatism. Such problems do not occur with Courier
or any other decent fixed width font.
Copy and pasting from some web page into a plain text email editor
strips out all font name, size, colour, bold, italic, underline,
hyperlink etc. information, which is typically a blessing.
In an HTML email, extra work is typically required at the compose stage
to make some text appear as a clickable hyperlink - and many people
either don't know how to do this or don't care to do so. This
means the recipient needs to copy and paste the text into their
browser, rather than simply click it in their email client.
Email clients used to handle plain text emails in a standardised way for replying - by including the original text, with a "
> "
at the left, so the sender could retain some or all of this quoted
text, adding their own lines under the relevant sections, without such
"quotation marks". This however raises problems of line length
growing unacceptably, especially with multiple reply cycles. A
Windows email client program from the 1990s, Pegasus Mail, used to do a
great job of intelligently reformatting such text, if required.
Netscape and later Mozilla Thunderbird generally make a mess of the
text with their reform options.
This is a fundamental problem with plain text emails.
Another is that some display devices are too narrow to support the full
line length used in a plain text email, such as 72 characters.
One response to this was to make "format-Flowed" the default method of
sending "plain text" emails from Thunderbird. This destroys the
ability to format text freely, as above, and instructs the client to
ignore line endings and reflow the text of whatever is considered a
paragraph to suit the display window. I was one of the people who
argued that it was a bug to make this the default, but whoever controls
these things retains it to this day, and the bug was reported in 2001:
Call me grumpy if you like, but the ability to use a simple,
long-established, method of email communication no longer exists,
unless one knows the reciepient's client can handle it. This is
due to sloppy programming and thinking, and choosing fancy,
overcomplex, eye-candy features as defaults, and ultimately as the only
mode of operation, for email client software.