On Friday 05 January 2007 04:33, Joachim Schrod wrote: > Randall R Schulz wrote: > > On Thursday 04 January 2007 22:31, Mike McMullin wrote: > >> ... > >> > >> Please don't ever send someone or anyone you might like, HTML > >> e-mail. > > > > Why not? Typographic variation is an age-old aspect of textual > > expression. There's no good reason to eschew it. Why should we be > > stuck in the 1970s when it comes to written, on-line communication? > > Because HTML are not readable in digests, mixed with plain text.
Fine. I'm not advocating it for every communication or in all venues. > Because people writing HTML email makes assumptions about the > facilities available at the receiver -- namely, that the > typographical variation can be seen there. This means that the > introduction "my comments are in red" are not meaningful if I read > that email in a terminal window over a slow GPRS connection. Or in a > black-and-white PDA. Yeah. It assumes they have an OS released within the last 5 years. > Because HTML emails tend to be much larger (again, not all of are on > broadband all of the time). Can you quantify that? 'Cause I don't believe that a few font variations have a significant bloating effect on message body size. > Because HTML emails can reference images and other stuff on the > Internet, leading either to dial-ups and privacy intrusion or > incomplete emails. Then don't allow them to be displayed in the client. I set KMail's HTML options (it has two: whether or not to interpret HTML and if it does, whether or not to fetch external resources) on a per-folder basis. Some newsletters I get are (at my option) sent in HTML form and may include images. Since I trust the sender, I enable full rendering. In other cases, I may allow HTML interpretation without image fetching. In my junk mail folder, I turn off both, though frankly there's no case when interpreting the HTML without fetching external resources is a risk. That's enough to be safe from the more nefarious uses of HTML email. > Because HTML emails are a prevalent intrusion vector for attacks. Only for naive clients and users. And for naively written software and clueless users, there are other worse vectors. > Because HTML emails are slow-dog for many recipients who use > Outlook. (Not that I use that, but I care for the recipients of my > emails, too.) I suppose you mean "dog slow." I don't know why that would be, since every HTML-capable email client I know just uses the same HTML rendering component used by other applications. (Eudora on Windows has the option to use its built-in HTML renderer or the system one.) > That's enough reasons to allow (i.e., whitelist) HTML emails only > for communication partners that are important enough for other > reasons to override these arguments. That's confusing enough that I'm not sure what you're saying. But again, I didn't advocate universal use of HTML, I objected to a categorical prohibition. > Emails are not a good representative of textual expression. In my > opinion, they have also many attributes of oral exchanges; its > informality not the least. And as with phone calls, I don't have > colors to tag important words either. Oral communication has other ways of indicating emphasis. *Asterisks*, _underscores_ and /slashes/ are stupid, feeble, ugly substitutes for real typographic controls. > Plain text is sufficient to express yourself here. If it isn't, put > more effort in it, it will pay back in getting better answers. Here, maybe. (Maybe not.) The statement to which I objected was: >>> Please don't ever send someone or anyone you might like, >>> HTML e-mail. This statement is much too sweeping. Personal communications is even more likely to call for styled text. > ... > > Joachim Avoiding and denying styled text in email is sheer Ludditism. Randall Schulz -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
