In <firstname.lastname@example.org>, 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. The reason people dislike HTML email is because email is a different type of medium, for which HTML is inappropriate. >> 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. > >Care to tell me just one thing that would make having a full featured >html formatting editor embedded in kmail harm users? > >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. >Will it prevent user for using plain text e-mails as they were used to? >No, it won't, users can still use their MUA in the way they prefer. Depends. Other clients in the past have grown test/html support in ways that make it very difficult, if not impossible, to write well-formed text/plain emails using them. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.