Comments on: Comprehensive guide to configuring mailers for plain text http://www.aquick.org/blog/2005/03/01/comprehensive-guide-to-configuring-mailers-for-plain-text/ entertaining hundreds of millions of eyeball atoms every day Sun, 12 Aug 2012 17:06:22 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: adam http://www.aquick.org/blog/2005/03/01/comprehensive-guide-to-configuring-mailers-for-plain-text/comment-page-1/#comment-213 adam Tue, 01 Mar 2005 17:29:24 +0000 /?p=600#comment-213 I'll accept that maybe some small amount of formatting would be okay for email. Personally, I find that there's nothing I want to convey in email that I can't convey in plain text (with text-equivalent annotations), with a URL, or a picture. The abuse of HTML mail frustrates me, and the fact that there's no distinction between "good HTML" and "bad HTML" makes this difficult to implement partially in a way that's not abusable. My biggest complaint is that under no circumstances should a mailer obscure the URL that the user is clicking on, yet this is possible in most of them. There's just no good that can come of that. I won't complain too loudly if people include a plaintext version, but I almost always refuse to read email that's html-only. I don't think that this is like the javascript argument. I really believe that while the web thrives on interactivity and design, I haven't seen a compelling argument that email is any better when there's more than just text. I’ll accept that maybe some small amount of formatting would be okay for email. Personally, I find that there’s nothing I want to convey in email that I can’t convey in plain text (with text-equivalent annotations), with a URL, or a picture. The abuse of HTML mail frustrates me, and the fact that there’s no distinction between “good HTML” and “bad HTML” makes this difficult to implement partially in a way that’s not abusable. My biggest complaint is that under no circumstances should a mailer obscure the URL that the user is clicking on, yet this is possible in most of them. There’s just no good that can come of that.

I won’t complain too loudly if people include a plaintext version, but I almost always refuse to read email that’s html-only.

I don’t think that this is like the javascript argument. I really believe that while the web thrives on interactivity and design, I haven’t seen a compelling argument that email is any better when there’s more than just text.

]]> By: Emmanuel Pirsch http://www.aquick.org/blog/2005/03/01/comprehensive-guide-to-configuring-mailers-for-plain-text/comment-page-1/#comment-212 Emmanuel Pirsch Tue, 01 Mar 2005 17:13:00 +0000 /?p=600#comment-212 I disagree! HTML is not meant only for the WWW. Textual communication is <strong>not</strong> meant to be plaintext. Formatting text allow to put <em>emphasis</em> on things that are important. The size argument is really weak... It's not like bandwidth and storage are scare resources nowaday. I believe Netiquette should mandate that there is always a plaintext version of the message if it's sent in HTML. This way, client that do not support HTML, can display the message properly. It is the mail client that does not support multiparts that is a bad citizen. As for background color or other formatting, they can always be modified using user CSS (granted the e-mail client must support it). This argument is very much like the argument against using javascript in web pages. Yes these things can be abused, but that does not mean we should not use them. I disagree!

HTML is not meant only for the WWW. Textual communication is not meant to be plaintext. Formatting text allow to put emphasis on things that are important.

The size argument is really weak… It’s not like bandwidth and storage are scare resources nowaday.

I believe Netiquette should mandate that there is always a plaintext version of the message if it’s sent in HTML. This way, client that do not support HTML, can display the message properly. It is the mail client that does not support multiparts that is a bad citizen.

As for background color or other formatting, they can always be modified using user CSS (granted the e-mail client must support it).

This argument is very much like the argument against using javascript in web pages. Yes these things can be abused, but that does not mean we should not use them.

]]>