On 2013-08-14, Professor Redwine <
jakob...@gmail.com> wrote:
> On Wednesday, 14 August 2013 03:10:40 UTC+2, Whiskers Catwheezel
> wrote:
>>... And far too many people seem to think that HTML or 'rich text
>>formatting' is appropriate in emails (it isn't).
>
> I suspect that the people and organisations entrusted with defining
> internet standards would disagree on that as a blanket statement.
> Inappropriate is the sending of emails that have no plain-text
> equivalent included (this directly violates standards) or where the
> officially nominated equivalent is so incredibly non-equivalent as to
> render the message useless if read in plain text (this is an
> in-principle violation of the standard). The latter can, at a pinch,
> be avoided with a statement to the effect that "the contents of this
> email cannot be effectively presented in plain text, but are also
> available online at ..." followed by a web link.
If you can't say what you need to say using plain text and binary
attachments, then email is the wrong medium entirely. (And don't attach
a word-processor file generated by whatever program you happen to be
using!)
> Much use of rich text in emails is inappropriate for the same reasons
> that much use of rich text in printed material, word processor
> documents, PDF files, presentations, web pages, etc. is inappropriate:
> it distracts, thereby detracting from the effectiveness of the
> communication. I personally find corporate templates that make an
> email appear as if it is on company letterhead to be overkill, but
> this is a matter of taste.
HTML and 'rich text' assume that the recipient has hardware and software
(including installed 'fonts') that match whatever the sender is using.
The HTML generated by email programs and word processors is pretty dire
even if it looks OK to the sender; few people have the skill or time to
code and debug efficient standard-compliant HTML that can be reliably
rendered by any rendering engine likely to be in use, just for one email
message. Even web sites often have to resort to offering different
versions for different web browsers, but at least they can "sniff" the
identity or abilities of the browser being used; that is impossible for
email.
The result is that the recipient may well see what looks like (and is)
garbled or daft HTML, unless their software is set to use the
'text/plain' version only, or to extract text from the HTML - in which
case the HTML is just junk, serving only to annoy the recipient and
waste bandwidth and time.
Then there are the privacy and security aspects; HTML emails can include
code that reports back to the sender every time the email is read, and
even which recipient's copy is being read, and from which internet
connection. Even worse is the possibility of "malware" being included
in the message or automatically downloaded. (Users in the know will set
their software to block such things even if the HTML is rendered, of
course).