On Wed, Jul 20, 2011 at 8:56 AM, Bjoern Hoehrmann <derhoe...@gmx.net> wrote:
> * Ghodmode wrote:
>>Is it a CSS-Discuss community policy, or the policy of an individual
>>who happens to be the list administrator? I suspect that it's based
>>on old practices for reasons that are no longer valid.
>
> Noting that this kind of discussion, even of marked offtopic, is usually
> not particularily well-received on the list, I can suggest to consider
> what features of "HTML mails" you find essential to talk about practical
> use of cascading style sheets and how you would avoid imposing choices
> you find appropriate on others. For instance, you would not specify the
> font you like because it's likely not installed on other users' systems,
> or because they configured the font they prefer to read emails.
Well, "essential" is too strong a word, but I think it would be nice
to have the ability to make text bold or italicized for emphasis.
Having a different font, indentation, and/or background color would be
nice for blocks of code.
Imposing choices on others? Allowing HTML wouldn't force use of HTML.
However, disallowing HTML forces use of plain text. That's what I
would call imposing choices on others.
Another point is that I didn't impose anything. I asked for feedback
from the community.
With regard to font choices, don't email clients handle that scenario
in a way similar to how browsers handle it... with substitution?
> You would not use images because they would make messages very big if
> they are specified inline or as attachments, or because they could be
> used for "tracking" if they are external. You would probably not change
> font sizes or colors because people tend to find that annoying and dis-
> tracting (you could use them well, but people usually don't). You could
> add that "HTML mail" editing interfaces are usually very poor and make
> it hard to properly encode, for instance, where you split a quote. The
> markup they tend to produce is often rather hideous.
That's right. I wouldn't do any of those things... In this, as with
all other things in a community, we would ask users to act
responsibly. Obviously, there's potential for abuse.
In my experience, most email clients act reasonably with fonts,
colors, etc. I've rarely had an inclination to view the source of an
email.
What email clients are you talking about?
> The point there is that if everyone excercises restraint in using "HTML
> mails", there isn't much left people could use it for to communite any
> better (as opposed to individualize the appearance of mails or whatever
> you may have in mind).
I disagree, but like I said above, allowing HTML in email would give
us a choice.
> On a technical level you create problems with spam filters as spam very
> often uses "HTML mail" for various reasons, and problems for the archive
> software as it would have to strip all sorts of markup for reasons of
> security. I would not read "HTML-only" mails because my client does not
> support them, and I've not seen them used sensibly virtually ever in e-
> mail discussions (though I see some benefits with "newsletters", in as
> much as "newsletters" are good use of e-mail as a medium).
Most email often uses HTML mail. Spam filters search for strings. I
subscribe to more than 20 mailing lists, few of them have this
restriction, but none of them have the problems you describe.
I really would like to know what email client you use. Even
text-based email clients can view HTML emails even if they don't show
the styles.
Here are 5 mailing lists to which I subscribe that allow HTML email
and don't have any of the problems you describe:
- Blueprint CSS : http://groups.google.com/group/blueprintcss
- Gnome-MY : http://mail.gnome.org/mailman/listinfo/gnome-my-list
- Greasemonkey Users : http://groups.google.com/group/greasemonkey-users
- WP Hackers : http://lists.automattic.com/mailman/listinfo/wp-hackers
- jQuery-UI : http://groups.google.com/group/jquery-ui
I did notice that most of my lists are from Google Groups... Almost
all of them are from Google Groups or Mailman.
> You can find arguments such as these in all sorts of articles on the
> subject on the web. In the odd event that you actually need some HTML
> feature to communicate better (say you gathered data about practical
> use of cascading style sheets and the best way to present it is in form
> of a table) and wish to tell the community about it, you always have the
> option to make a web page and post a link. And for the little things
> like emphasis there are *alternatives available* with plain text.
I agree. "need" is too strong a word. I'm just saying it would be
nice.
> So, no, this is not based on some individual's personal preference but
> rather on the experience with what works and what doesn't of many, and
> various issues that arise from "HTML mail" usage as they can be observed
> in practise. If you think you can make a convincing argument that "HTML
> mails", all things considered, are better, by all means write it up and
> post a link; if it is indeed convincing, things are likely to change.
If I wrote up an article, that would sort of negate the necessary
community feedback, wouldn't it?
> In any case, this isn't the right place to make such an argument as it
> is not specific to this particular list (you can make the same argument
> for any HTML or webdesign or related list).
It's the only place to have this discussion. It pertains directly to
the people who receive these emails.
I really appreciate your feedback on this. I was asking for a
discussion and greater understanding. I truly didn't think that there
were people who (still) thought the way you do about HTML email.
--
Ghodmode
http://www.ghodmode.com/blog
______________________________________________________________________
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
