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

[Carlos Morgado <chbm chbm nu>]

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.

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

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

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

"i sent you blahblahblah"
"i didn't see it like that"

doesn't seem like a good solution


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

i think gtkhtml only uses user fonts, not sure about that

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds