HTML support (was Re: Simplification of preferences)

[Brian Stafford <brian stafford uklinux net>]

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