In <[🔎] pan.2010.10.31.19.35.06@gmail.com>, Camaleón wrote: >On Sun, 31 Oct 2010 13:51:04 -0500, Boyd Stephen Smith Jr. wrote: >> In <[🔎] pan.2010.10.31.16.29.12@gmail.com>, Camaleón wrote: >>>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote: >>>> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): >>>>> I don't know how can you equate all that stuff with having html >>>>> e-mail unsless you also avoid using Internet (websites use html and >>>>> not plain text and we are all happy with that). >> >> The web was founded on text/html. Email was founded on text/plain. The >> web is a pull / request model. Email is a push / send model. The web >> operates through multiple linked requests. Email expects everything >> inside a single message. > >It is called "evolution". > >The first hypertext applications were not very dynamic, I'd say, just >text and some links to jump to. Just look around now what the web has to >offer. Yes, because HTML (in particular) was designed with that in mind. Gluing together of disparate resources in a relatively full-featured client. Email was NOT designed this way. It took decades before it could handle attachments sanely. MUAs should not be expected to even be ABLE to fetch resources that are outside of the current message. There are proposals I've seen for using URIs in the HTML that resolve to other parts of the same MIME structure, but they are not followed by (m)any MUAs, particularly composers, and they all seemed a bit fragile as I was reading them. >> The reason people dislike HTML email is because email is a different >> type of medium, for which HTML is inappropriate. > >I can understand people dislike that things, but forcing their own POV to >the rest of the users is not a fair approach. In that reasoning, we could >still stay with "us-ascii" encoding and ditch "utf-8", but nowadays I >wouldn't find it quite appropiate. Use a different, more appropriate, medium if you want to use HTML. The push / send model is not appropriate for the gluing together of disparate resources, in particular untrusted resources. When using the web, you are using a pull / request model. In this case, server dictates the terms. The UA must accept and process whatever the server deigns to deliver as part of the request, and the user must seek out a UA with the right features in order to satisfy their needs. In this model, "evolution" moves quickly, since new features are adopted by a users in order to handle response from more servers. When using email, you are using a push / send model. In this case, the recipient dictates the terms. The MUA must only create and send data that the recipient is willing to accept or the effort is wasted, and the user must seek out a MUA that can reach the most recipients. (In a support context, more recipients = more replies = more useful replies = better support. In a marketing / community context, more recipients = more eyes = more inquiries = more sales / members.) In this model, "evolution" moves slowly, since new features are avoided by users in order to reach the most recipients. I have descent bandwidth, to doing a reasonable multipart/alternative message will reach me. You send in text/html and your message just goes in the round file. Others don't have the bandwidth to waste / spend; multipart/alternative messages reach their round file. Still others will accept all 3 forms. If you want the most people to see your message, you'll use text/plain. >>>> I was not equating anything with anything, I was just trying to make a >>>> distinction about features not always being choices and vice versa; >>>> and about features not always making us better off. >>> >>>Sorry, but I fail to see how "adding" new options can be "bad" for >>>users. >>> >> Paradox of choice. Fewer options is easier to understand. If the new >> feature is not the default, how will we show it off; if the new feature >> is the default, the existing user base will complain. > >But I'm not talking about "defaulting" KMail to html e-mails. Plain text >e-mails can be defauult choice, I have no objections to that. People is >smart enough to switch over text/html if properly indicated inside Kmail >UI (an actually I know it is) and even if the user cannot find it, he/she >can always ask in mailing lists or forums on how to change it. That was 3 reasons, not 1. You still haven't addressed "Paradox of choice" (a practical, documented usability problem) or "Fewer options is easier to understand". I must have snipped too much, but you mentioned UTF-8 vs. US-ASCII. UTF-8 doesn't replace US-ASCII, the replaces dozens of different ways to handle bytes that are not in US-ASCII. Using UTF-8 rarely reduces the number of people your message is seen by. If it is all US-ASCII character, then the UTF-8 encoding is a no-op and everyone that could read it before can still read it. If it is not all US-ASCII, then you've traded users of specific other encodings for users that can read UTF-8. In certain forums, it *still* might be best to use an encoding other that UTF-8, but not on a Debian forum. (Since UTF-8 is so well supporting in Debian oldstable and above.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.