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

["M. Thielker" <balsa t-data com>]

On 2002.11.14 13:26 Brian Stafford wrote:
[...]
>> - 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.
[...]
> 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.

True, but there also _are_ broken UAs out there. Most UAs of the current 
generation simply assume that the recipient can and will render html. 
Therefore, in a (futile) attempt so save bandwidth, the text/plain 
duplicate is replaced by that message. It's sent as multipart/alternative 
because they only want you to see it when your UA cannot display html. Were 
they to send this as multipart/mixed, some UAs, like M$, would render the 
second (text/plain) portion inline, giving the impressin that the text is 
part of the html content. M$ will, with multipart/alternative, never give 
any indication that anything other than html is present, it will render the 
html part, and that only, hiding the other parts from the user, who is 
judged too stupid to understand the structure of mail messages. Most of the 
time, that assumption hits the mark with M$ users.

>> 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.

Well, IMHO the RFC is wrong there. I am the one who must look at it, I 
should have control over what I see. If the sender wants to use flowered 
backgrounds, I do not think that I should be forced to see it if I don't 
want to.

> 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.

As I said, I think the RFC is flawed there. Anyway, that would be an 
option, otherwise, see below.

> 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?

Very good idea! I would go for that. Have an option to render HTML as text. 
That would neatly solve the problem with those invalid multipart/mixed 
messages.
Assuming it's the intention of the sender that I should see the content 
that is in the text/html part, that solution would provide the means to do 
so without forcing me to see the markup as well. Short of keeping people 
from sending html at all, this is the best thought on the subject I have 
heard so far. In the end, the RFC says nothing about the sender controlling 
the way the designated part is rendered, it only says that the best (first) 
part that can be rendered should be rendered. How it is to be rendered can 
therefore be safely put under control of the user without even getting 
close to a RFC violation. Yes, this is the way it should ultimately be 
implemented, I think.


> 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.

Yes, I had forgotten Anchors. I would not want inline images. While it 
would be nice to see images in the textual context they belong to, I see 
too much possibility for abuse there. It would tempt too much to use images 
as textual elements, pictures of text, if you so will. By taking the images 
out of the textual context, this abuse effort can be thwarted. Otherwise, 
some people who really think I must see their yellow-on-violet text with 
butterflies would just make a jpeg of it and put it inline, forcing me to 
see it and to strain my eyes deciphering flowery script on patterned 
backgrounds.

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

Most of the time it would get abused, I think.

> 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.

Well, AFAIK both NS and IE offer options to ignore page colors and set text 
and background color to fixed values. Rudimentary, but it's there. IE also 
offers to inhibit loading of images until instructed to do so "right click 
-> view image".

Regards,

Melanie