From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-07 11:22:35
I hate to be a buzz-kill, people, but this is getting a little too serious
to be considered on-topic for boost...
----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
Sent: Friday, June 07, 2002 12:05 PM
Subject: Re: [boost] Re: HTML-format mails
> >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
> same policy on the ACCU mailing lists - no HTML mail. In fact, any HTML
> is automatically stripped by the mailing-list software. Which makes the
> 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,
> the grounds that it took more space to send. If you only send the HTML
> it more or less takes the same space, though. If you were to use some
> 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
> text mail.
> So I found this argument rather reactionary, when you consider the
> 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
> stranger given that it's common to send movies or music across Internet.
> 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
> the compilers, and therefore the vendors, to make more compliant
> However, because Boost also aims to be portable, also for not so
> compilers, the libraries are typically made more portable, across
> The same argument may be used for mailing lists. There may be a wide
> of mail clients, however they all at least support plain text, as a
> denominator. Also, even if the clients do support HTML, some may not want
> use it.
> Therefore, I've tended to only use HTML mail, if I've known the other
> 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
> for the rest of the mail - the wrapping is adjusted to the size of the
> 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
> I think HTML mail is reasonably well standardized, since it uses MIME,
> which, as I understand, is part of the SMTP/POP standard, now.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk