On Sun, 2003-02-02 at 23:32, Christopher Cashell wrote: > At Tue, 24 Sep 02, Unidentified Flying Banana Nick Walter, said: > > I completely understand and agree with "Respect for open standards" > and also > > "No M$ Word docs in e-mail". > > It's not just a matter of open standards, but access. Every e-mail > client in the world can handle plain text e-mail. Many cannot view > other formats. That's changing. Even venerable Pine can read HTML. > > I can't, however, quite agree with "No HTML/RTF in e-mail". Both > HTML > > and (theoretically) RTF are open formats that are well supported in > a > > variety of O/Ss. > > They are well supported within certain programs in a variety of OS's. > That doesn't mean that every e-mail client is capable of reading them. > Nor should it have to. But they are approaching that anyway. See above. > > Using these formats is not contributing to anyone's evil monopoly or > > excluding a Linux/*BSD user from reading the document properly. > > My primary e-mail client is mutt. It's a console based program which > works best with plain ASCII text. It was designed to be an e-mail > client, and nothing else, and it works amazingly well for that. Now, > it > can utilize external programs to view non-text attachments, such as > HTML > and RTF, but doing so is slow, cumbersome, and difficult. > Additionally, > trying to reply to HTML/RTF e-mail is very bothersome, particularly > with > accurate quoting. That's a problem with your MUA, not with HTML per se. Once widely-used MUAs are sufficiently up to the task of dealing with HTML, this is likely to change. > Many (most?) PDA e-mail programs have difficulties with HTML/RTF > e-mail > still, as well. RTF, maybe. HTML, no. It is quite possible to ignore undesired markup in HTML documents, if you can't render images and such. Again, PDA MUAs will need to improve so that they actually do this; that will come with time. > Not everyone is on some sort of broadband Internet connection yet. In > fact, the vast majority of people aren't. Sending an e-mail as HTML > will generally at least double the size of the e-mail, and frequently > more. I've seen some HTML e-mails that were more than 5 times the > size of their plain text equivalents. I'm not sure if you know this or not, but because all those HTML tags are repeated strings, Deflate works very well on them. The size inflation is therefore not particularly important. Images, on the other hand, are another story. > Many people dislike HTML e-mail, even if they can read it fine. > Reading > HTML means that you have to deal with color and font changes, text > size > changes, links, tables, etc. If you don't like it, configure your MUA to ignore it. > This can be distracting at the best of > times, and downright frustrating at the worst. Many people like to > change the background color of their HTML e-mails, or change the text > color. Few of them have any experience with Human Factors or > Interface > Design, and most end up making their content more difficult to read. > Lastly, HTML is much harder to translate into braille or reading > devices, making it more difficult for those with vision impairments to > use (I'm familiar with this one because a good friend of mine is > legally > blind). If there are lots of images or tables involved, then yes, this will make things harder. Normal text, however, is not a problem. Last time I checked, most HTML email (except for stuff sent by companies, who are trying to make themselves look 'professional' with their extravagant HTML) consists of normal text, laid out in the same way as a plain text email, but perhaps with some bulleted lists or such. > I've set up my computer, and my e-mail client, in order to make > reading > e-mail as easy for me as possible. This only works when I'm allowed > to > specify my own colors, fonts, and styles, though. And you should always be able to. If you can't, bug your MUA maintainer! > And don't forget that > while it may look one way on your machine, it may look differently on > mine. When you have to deal with as much e-mail as I do daily, you do > everything you can to simplify it. Fine. Be my guest. > Many people have noticed that the majority of Spam is sent as HTML > e-mail Not for me. > and that the majority of HTML e-mail is Spam. Again, not for me. Much of the spam I receive is plain text. > For this reason, > many mailing lists and many people filter all HTML e-mail as spam, and > trash it. In fact, I frequently do this myself, and I'm on numerous > mailing lists which reject HTML e-mails. If your spam detection heuristics rely on the email containing HTML as a hint that it's spam, they are in dire need of revision. See above. > As was commented in the message that started this thread, HTML e-mail > can have extremely nasty effects for people who read mailing lists in > Digest mode. Digest mode is where all of the messages that are sent > to > a mailing list are packaged together, and then periodically (usually > daily, weekly, etc) sent to the list digest subscriber. When HTML > e-mails are included, you end up with a large text file sprinkled > through with HTML that will be entirely unreadable for those trying to > sort through the e-mail digest. Digests should consist of a multipart message, where each part is a message/rfc822, containing one of the emails being digested. That avoids this problem nicely. This has several other useful benefits, as well. > HTML e-mail is also responsible for what I consider one of the worst > things to happen to e-mail. . . it's breach in security. For years > and > years, it was common and accepted knowledge that there was absolutely > no > way you could be affected by any sort of virus simply by reading your > e-mail. And it was a fallacy. I understand the popular mail reader Pine is _full_ of remotely exploitable buffer overflows. > It was impossible. Couldn't be done. You had to execute a > program first. That fact is no longer true. And not only that, but > it's gotten worse. E-mail based viruses, utilizing HTML, JavaScript, > VBScript, and holes in the HTML rendering engines required to view > HTML > e-mail have become among the fastest growing and most damaging virii. Interestingly, you forget to note that only Microsoft Outlook is affected by any of them. As much as you may think otherwise, this is an Outlook problem, not an HTML or JavaScript problem. Otherwise, Mozilla would have the same problems when viewing Web pages. > We've gone from a 100% safe medium of communication to opening some of > the biggest security holes in the history of the Internet, simply to > make e-mail more "pretty". Again, it was hardly 100% safe. See above. > Finally, I'll end with the most important reason. . . it's > unnecessary. > There is really no good reason to use HTML or RTF in E-mail. I've > been > sending and receiving e-mail for over 10 years now, and I've never > encountered a situation where I absolutely had to send e-mail using > HTML. The whole point of an e-mail is to distribute thoughts, ideas. > . > . content. Content is words, not flashy colors, blinking text, and > italic or bold letters. Content is also formatted lists, tables, and a variety of other things that can be done in plain text, not that I recommend it. Tables, in particular, are terrible in plain text, because you have to limit them to 72 characters in width, which makes them very badly squashed and hard to read. > If you have something that you simply *can't* send as plain text, I > suggest either reconsidering what you're sending, or posting it as a > web > page (where HTML was meant to go) and e-mailing a link to it. So, you'd prefer to have 16 million Tripod-originated pop-under ads instead? > I hope this hasn't come off as too rude or unfriendly, but this is > something that has always annoyed me, along with other examples of > poor > netiquette such as poor quoting and trimming in e-mail replies, random > attachments, etc. Define 'random attachments'. You mean vCard attachments and such? Alex. -- PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N- o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI D+++ G e h! !r y ------END GEEK CODE BLOCK------
Attachment:
signature.asc
Description: This is a digitally signed message part