HTMLised email

Chris Adams pmmail@rpglink.com
Sat, 11 Dec 1999 11:41:59 -0800


On Sat, 11 Dec 1999 15:06:34 -0400 (AST), Trevor Smith wrote:

>On Sat, 11 Dec 1999 16:46:46 +0000 (GMT), Simon Bowring wrote:
>
>>Lets keep email text-based and standards-compliant
>>so that every one can interchange messages without pain.
>
>Or at least make a damn HTML-email standard and stick to it. I agree,
>Netscape is guilty of breaking things on purpose to rope in the
>rubes. MS, ironically, wasn't the first to do it in this market.

There are three big complaints I have with HTML email:

1) Size - not just for people downloading it but also remember that HTML messages have the entire message sent twice (once in plaintext, the other in HTML) & the HTML is frequently very bulky. From 
a mail server admin's POV this is annoying (e.g. 200K extra bulk on the CEO's pablu^H^H^H^H^Hletter to 5,000 employees).

2) Different formatting tastes - I set up my mail reader preferences the way I like to read my mail (e.g. color, font, size, etc.). HTML adds only two things that weren't easy to do with ASCII - 
color and tables - and ignores my settings, meaning that I get to see some AOL luser's complaint to postmaster ("The mailing list I subscribed to is sending me email! Make it stop!") in all of its 
64 point blinking gray-on-black glory.

3) Security - now the old urban legends about email viruses are true, to say nothing of the privacy issues that've come up.


Concern #1 is becoming less of an issue thanks to the ever decreasing cost of bandwidth and storage. 

Concerns #2 & #3 are failures on the part of the mail clients. I like the idea of formatting email, particularly with CSS, for large documents (although there is always the "If it's over x bytes, 
put it on a webserver & send the URL instead" line of thought) but the client needs to allow me to override the message. This could work nicely if I could provide my own stylesheet to override the 
message's formatting. #3 would be solved as soon as they allow more control over the security of the HTML rendering widget (e.g. "Don't run scripts", "Don't run applets", "Don't load anything from a 
remote server").