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

[Toralf Lund <toralf procaptura com>]

> On 2002.11.14 13:35:21 +0000 M. Thielker wrote:
>> On 2002.11.14 13:26 Brian Stafford wrote:
>> [...]
> 
>> 
>> 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
> 
> seems to me there is no attempt to do anything mildly usefull, it's just
> broken crap like craplook send /alternative text and ms-tnef
> so i feel no great love for those messages
> 
>>> 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.
>> 
> 
> presentation might bear into message content so i think the rfc is right.
> anyway, when in doubt follow the rfc. when in disagremeent, comment the 
> rfc.
Agreed.

>> Very good idea! I would go for that. Have an option to render HTML as 
>> text.
> 
> html->text converters rate as "big crack" on my book. those things tend
> to always end up as an html2 renderer written by a mad monk.
We should definitely not add HTML rendering code. Converting via an 
existing lib or external app might be acceptable, though. I once submitted 
a patch that did the latter...

> 
>> 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
> 
> markup knows strikethrough, quote, heading and sub/sup. that's just 
> html3.2
> and markup that alters the content.
> "big crack"
> 
>> 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.
>> 
> 
> one could defend text parts should be displayed as pictionary ridles. 
> that,
> while being very amusing would upset most senders.
Good point, again.

>>> 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
> 
> you mean img src="http" or img src="cid" ?
None of these work in Balsa anyway, as far as I know.

>> 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.
>> 
> 
> you should try to fix your correspondents instead of breaking you MUA :)
Quite.


- Toralf