HTML support (was Re: Simplification of preferences)
- From: Brian Stafford <brian stafford uklinux net>
- To: balsa-list gnome org
- Subject: HTML support (was Re: Simplification of preferences)
- Date: Thu, 14 Nov 2002 10:14:33 +0000
On Wed 22:45, 13 November 2002 M. Thielker wrote:
wrt HTML mail a few comments...
> I, personally, don't want even rudimentary html support for outgoing email.
> I don't want to send HTML mail. I don't really want to see HTML mail. I
> would like to abolish HTML mail altogether, but it seems to be here to stay.
Agreed. I feel that a richer text format in email would be a good thing, but
HTML is totally the wrong way to go about it.
> I am strongly considering working up a private patch to suppress HTML if
> text/plain is present in multipart/alternative.
This would be a good thing for the reasons you describe below, amongst others.
> It's been discussed here before, but it seems our RFC gurus set standards
> conformance before usability and, even though such a pref would not change
> the way Balsa behaves on the net, but only what the user sees, they don't
> want it.
I'm not sure who you mean by RFC gurus - the authors of the relevant RFCs or
myself and others who have struggled to interpret their meaning. I have
discussed what follows before but I am not convinced I have made my point
clearly. I shall try to do so again as I believe that at least my position
has been misunderstood.
The documents referring to multipart/alternative *do not* mandate the ability
to support a particular content type (ignoring text/plain issues). What is
mandated is that the program should select the "best" available rendering of
the document from the intersection of the set of document versions in the
multipart/alternative and the set of supported features in the program. This
ensures that the intentions of the message sender are respected - and properly
so. Another important point is that the definition of "best" in this context
is the ordering of the parts within multipart/alternative; not whether, for
example, an application/postscript might look visually to be of higher quality
than text/plain. Furthermore, the MIME RFCs do have any say over user
selectable features of any program - this is completely out of scope, barring
interoperability issues.
The ability to render text/html is not a normative requirement of any mail
related RFC and the ability for a mail UA to do so is certainly not an
interoperability requirement. Therefore a UA might have a user selectable
feature which enables support for text/html. When enabled, the UA
automatically selects text/html when it is the "best" rendering of the source
document according to the rules for multipart/alternative. When disabled, the
UA selects another rendering of the source document as "best". In both cases,
the UA is conformant; I have never found text in RFC 2045-9 or their updates
that suggests otherwise.
In conclusion, I support the idea of adding a user selectable feature to
enable text/html rendering. There is nothing here which violates any RFC. I
do not, however, support any change that alters the behaviour of the algorithm
which selects the "best" part within multipart/alternative as this is mandated
by the RFCs.
The same argument applies to rendering of other content types, such as
application/postscript.
> I would like to have it, though, especially since the mouse wheel doesn't
> work in HTML view and I have to use the scrollbar to scroll down to the
> icons and select text/plain. It's a pain.
I agree.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]