Re: HTML support (was Re: Simplification of preferences)

[Brian Stafford <brian stafford uklinux net>]

On Thu 10:57, 14 November 2002 M. Thielker wrote:
> Hello,
> 
> On 2002.11.14 11:30 Carlos Morgado wrote:
>> On 2002.11.14 10:14:33 +0000 Brian Stafford wrote:
>>> On Wed 22:45, 13 November 2002 M. Thielker wrote:
>>>> 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.
>> simple, build --without-gtkhtml :)
> 
> Unfortunately, that's what I want, but not what I need. I receive 3 kinds of 
> email:
> 
> - Messages that have both text/plain and text/html parts with equal content. 
> With those, I would want the default to be text/plain.
> - Messages that have both text/plain and text/html parts with _differing_ 
> content. In most cases the text/plain part only contains the message that my 
> mailer is unable to render html and I should use another mailer to view the 
> message. In that case, I need a simple way to render the HTML, launching an 
> external browser for that is too cumbersome.
> - Messages that have a text/html part only. On those, html should be 
> rendered by default.

I'm in roughly this position too.  I would like a UI selectable runtime 
equivalent of --without-gtkhtml.  Doing this would never violate the 
multipart/alternative rules.  Note that messages in the second category should 
never be sent as multipart/alternative.

> The change I require would be the option to prefer text/plain over 
> text/html, if present. Now, I know that some others here have in the past 
> voices similar opinions, but were overruled by the ones I mentioned in my 
> original posting.

This is trickier - since it overrides the message sender's intentions.  
Perhaps a compromise position is to make it a second option, independent of 
whether HTML is enabled or not.  The justification might be that it is in 
compensation for broken sending UAs.

I feel that the enable HTML rendering preferences checkbox option should 
always be built as there are no philosophical problems associated.  An option 
to override the multipart/alternative algorithm should be selected by an 
--enable-xxx option to configure *and* a preferences checkbox.  That way a 
Balsa which can't be configured into RFC non conformance can always be built.

> ... I don't need to see fancy stationery and hard to read "script" fonts in 
> impossible colors that blend into the background. ...

Neither do I.  Nothing in any IETF or W3C documant mandates *how* HTML is to 
be rendered.  Gtkhtml is certainly not needed to do this.  An alternative 
which ignores the markup and simply extracts the text might suffice.  Anchors 
could survive this process, after all, balsa's plain text rendering already 
highlights urls.  Might it be possible to port something from a text mode 
browser or to do something using libxml2's HTML parser?


> Disagreeing with Brian, I have to say that I don't believe that anything 
> much "richer" than plaintext is needed in email. It would be ok to have bold 
> and underline attributes.

I'm not sure you do disagree with me, I didn't say how much richer.  At the 
risk of drifting off into another topic and dreaming for an ideal world which 
isn't going to happen...

Bold, underline, italic, perhaps inline images and maybe anchors would 
suffice.  And it should not be possible to select more than one of bold, 
italic or underline at once.

> I wouldn't want font size control, much less font face control and I 
> definitely would not want background graphics.

This stuff gets abused.  Most punters haven't a clue about good presentation 
and sadly giving them the facilities leads to unreadable content.

> Illustration graphics would be ok, though, but it would IMHO be sufficient 
> if they are sent as attachments.

Sometimes it's nice to see them in the context of the text referring to them.

> COlors I also wouldn't want. In all cases I have seen, any of these 
> attributes (font size, font face and text color) were used to make things 
> harder to read. Many people seem to think that bright green on white is ok, 
> I can barely see that combination. Yellow on purple or green is also common, 
> it hurts my eyes to see it.

As I say, most punters haven't a clue about presentation.  But also bear in 
mind, according to the W3C, that presentation is supposed to be under control 
of the reader - in particular the partially sighted often need bizzare colour 
combinations to get readable text and these can often be uncomfortable for 
people with normal sight. Not, of course, that the major browsers or even 
gtkhtml offer them a simple facility for the user to override colour, font 
size, etc.  But that is a rant for another day.

> So, to me, html is for the birds, a last resort choice when there is no 
> plain text.

I don't think anyone here disagrees with that opinion


Brian