Re: [boost] Re: HTML-format mails

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-06-07 11:05:44

>From: "Mattias Flodin" <flodin_at_[hidden]>

>A more appropriate metaphor would be C++ compilers for embedded systems.
>Full support for the minimum standard, but running in a rather
>restricted environment. And, afaik, we do want to support that. :)

Just to give my 0.02 on this, as well.

I can understand the resistance to HTML mail on a mailing list. We have the
same policy on the ACCU mailing lists - no HTML mail. In fact, any HTML part
is automatically stripped by the mailing-list software. Which makes the mail
look rather funny if it _only_ contains an HTML component, as it then
results in an empty mail. :)

James Curran said in the original posting:

>    With compilers, we write to the most modern standard, begrudgingly
>support old compilers, and consider those to insist on using such old
>compilers as holding back progress.

I can understand this notion very well, because I reacted with similar
disbelief, when someone I know, a programmer, refused to use HTML mail, on
the grounds that it took more space to send. If you only send the HTML part,
it more or less takes the same space, though. If you were to use some kind
of non-HTML markup, you'd need to mark it some way, anyway, like
_underline_. Also, if it was sent compressed, it should be about as small as
text mail.

So I found this argument rather reactionary, when you consider the benefits
of being able to format the text. It would be like the change from plain
text, to word processors, to finally also happen for email. I find it even
stranger given that it's common to send movies or music across Internet. The
bandwith taken by email, text (HTML or not), for people, would typically
only be a tiny amount of the bandwidth used for web access.

However, for mailing lists, this may be different.

Coming back to the compiler argument. Yes, it's nice to be able to write
standard C++, and the Boost libraries (and libraries like Loki), really push
the compilers, and therefore the vendors, to make more compliant compilers.
However, because Boost also aims to be portable, also for not so compliant
compilers, the libraries are typically made more portable, across compilers.

The same argument may be used for mailing lists. There may be a wide variety
of mail clients, however they all at least support plain text, as a common
denominator. Also, even if the clients do support HTML, some may not want to
use it.

Therefore, I've tended to only use HTML mail, if I've known the other one's
mail client was able to handle it (which you can often tell from the mail
header). It can be quite useful for sending code, because you can use
fixed-space font for that part, and you avoid the wrapping. That also goes
for the rest of the mail - the wrapping is adjusted to the size of the text
window, rather than some arbitrary limit.

However, for mailing lists, like the Boost libraries, it may be better to
use a common denominator handled by all mail clients, or preferences.

>It has just elected not
>to support HTML format mails (which, afaik, are not part of the SMTP/POP
>standard).

I think HTML mail is reasonably well standardized, since it uses MIME,
which, as I understand, is part of the SMTP/POP standard, now.

Regards,

Terje