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

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

>> 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 :)

- Toralf

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]