> HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place. The few advantages they offer for end-users, such as links, inline images, and bold or italic text, aren't worth the trade-off.
Inline images are a huge, huge advantage, especially for internal business communications where an email may be the only real documentation of a problem and its solution. (Or at least the only documentation that can stand on its own -- the alternative is usually a PowerPoint deck with missing information that was only given in a one-time presentation.) Being able to add a graph or a table or a schematic or a photo is important for anyone who works with non-text data. I suspect some programmers may be unaware of how unusual it is to work entirely in text.
Maybe emails shouldn't be primary documentation. They were never designed for that, and shoehorning them into that role has ruined the entire experience.
For example, my workplace no longer allows forwarding or IMAP access because of this, so I'm forced to use the sh*tty Outlook web client, which wastes untold numbers of minutes each day waiting on the damn thing to load something. Just now it wouldn't let me open a PDF in a native client, because I guess Microsoft is so obsessed with locking us into their ecosystem. Instead I had to save it to disk first then go to the file manager to load it. (Yo, MSFT, this is why people hate you.)
I strongly agree, but good luck pushing that idea in your nearest large corporation. The lack of concern for communication and record-keeping I've seen in my career is simply appalling. Simple things like minimal proofreading are treated like pulling teeth, and heaven forbid someone rename a file so you can actually tell what's in it. At least an email is a proper written document, unlike the half-assed PowerPoint slides I usually see.
I agree that there are better ways to keep things documented. Any fix communicated over email might as well include (or even better only include) a link to the actual documentation wherever it actually belongs, but that's a terrible reason to abandon IMAP and force people to use Outlook. It's so terrible a reason it's hard to imagine that was their only one. I imagine most companies are more worried about leaks or compromised email accounts than about documentation ending up saved in email only.
Those things you mentioned are a-ok, but including a photo in the email signature really bugs me. There are times when I want to look for emails with an attachment, but often the company logo in the signature causes false hits.
What really bothers me is when someone copy and pastes something they've written in MS Word into their email and turning the email into HTML without even noticing. What's even worse is when people bump up the font size of the entire email body because they think since their email client has a small default font size it must be the same for everyone else, I've seen tech CTO's do this to, sometimes you wonder what the technical chops for a position like that really is.
Yeah, rich-text copy and paste is pretty awful. The default in almost all cases should be "paste without formatting", but instead you have to go out of your way to exclude formatting.
One nasty thing that Word does in this situation is to effectively convert any included jpegs into pngs. That cute little pic you included as a header is now 800k when it hits the email list.
Images can just be added as attachments however, they don't have to be inline. Many GUI mailbrowsers can display them as previews. If for some reason they are absolutely required to be inline of text, its easier on the recipient of the message, if the document is composed as a separate file (pdf or whatever), and sent as attachment.
I remember that it was possible to insert inline images in a plain text email by adding a uuencoded block in the middle of the message. MIME also had inline attachments, but those typically show up at the end of the message.
In pouring over the relevant RFCs fairly recently in order to implement my own client, I learnt (though didn't implement - raised a not implement exception, and I've yet to receive exceptional mail) that you don't actually need HTML for inline images.
Tl;dr a multipart message can include an image with an inline 'content disposition'. It's intended that clients show it inline, but I suspect many don't. Like I said I haven't received any yet anyway, so it's probably not that consequential.
Another quirk I'm aware of, by implementing my client quite unforgivingly, is that many emails are structured with the attachments only 'tied' to one alternative, often the text/plain media type, so if you interpret the parsed tree structure of alternatives/attachments literally, the HTML-formatted message might refer to an attachment (I mean a PDF say, not an embedded image) that's actually only available on the plaintext version. Having never encountered this before, I'm pretty sure other clients (like Gmail, Fastmail) present all found attachments alongside whichever alternative is viewed, not taking the actual email too literally (as I presently do).
I think it's significant that this is written in the passive voice. Because written this way it has the semblance of officialness, of generalness. Whereas writing it in the active voice would reveal that the people doing the preferring are just the people who made this website, and this preference is just that: a preference.
I love HTML emails, because I use italics basically all the time in my writing, and underscores _just don't offer the same experience_.
There is a standard text/enriched content type that enables only “text formatting” and not arbitrary HTML. But HTML rapidly took over email, and now I don’t know what clients even implement text/enriched anymore.
In normal text (i.e not Markdown), using /slashes/ can get the idea across more visually. I think I picked it up on Usenet where it was reasonably common.
Right above that line, the site notes that the code is available here [1]. It looks like the majority of it was written by Drew DeVault, who runs SourceHut [2], where the code is hosted.
Yeah I used to be a text fanatic and then started seeing the value in making things stand out in HTML. Lol, some co-workers just don't get things that aren't in bold or well-formed bullets. I rarely put in images, but when I do having them inlined is indeed valuable. I just wish we had a proper subset, though. Maybe markdown would have been way better if it was around and well known at the time.
"Because written this way it has the semblance of officialness, of generalness."
I agree with you. Moreover, there's very little chance of any agreement about this in the foreseeable future. Those who believe that plaintext is God's gift to emailers will never change their views. They've held these views for many decades, so there's precious little chance of them doing so anytime soon.
We've seen this all before in many other endeavors both technical and nontechnical. Those who wrote with quills and fountain pens said that writing would go to the dogs if ballpoint pens became commonplace.
Fortran programmers resisted going from upper to lowercase (even now, this modern browser editor has a hangover from that long gone era as it automatically converted 'Fortran' to uppercase as was the once custom). As a longtime Fortran programmer, I'd suggest that if decisions about the human-computer interface were left to my kind then we'd likely still be using uppercase ASCII and telex machine would still be fashionable although perhaps considerably faster.
As is usually the case, there's often some truth to the arguments and promoters of a cause buttress them up with historical usage or precedent so as to strengthen their case. Making their arguments sound credible is an essential part of convincing neophytes and potential converts that they're right.
I'll briefly go back to the fountain pen example for a moment as it's analogous to this case and it's simple and easy to understand. There's considerable evidence that when the ballpoint pen overtook nibbed pens a little after WWII that writing did in some ways go to the dogs but the ballpoint only shares part of the blame, things were much more complex than it alone.
I have some authority in saying that as I'm a regular user of fountain pens and I own quite a number of them. Moreover, my writing is much less sloppy with them than when I use ballpoints not to mention the fact that I actually prefer writing with a nib as it provide much better haptic feedback than do ballpoints. There's little argument about that and the evidence is easily demonstrated by examining the writing of current users of said pens.
That said, that's only part of the story. There are also other reasons for why writing deteriorated at that time but it's off topic so I won't go into specifics. However, the relevant point with this example is that the promulgators of nibbed pens only promote their benefit - that of better handwriting. What they omit and never tell you about are the many disadvantages that nibbed pens have: ink gets everywhere, they're messy and time consuming to fill even when using ink cartridges - and probably the worst of all: take a fountain pen on a plane trip and the reduced air pressure forces ink out and all over one's shirt pocket. Right, there couldn't be a worse place for that to happen. And it happens frequently (I know from experience).
Back to plaintext email, it's what its promoters do not tell you about that's the real problem. The list is long but there's little point detailing them all here except to say that two stand out. If images and tables cannot be included as inline information then either they're likely to be lost or misplaced and second, that having to encode and transmit them separately by other means is both time consuming and error prone even if done within the same email client.
Moreover, plaintext doesn't have the range of glyphs and or the means of displaying them so that the presentation of the message information is simple and easy for the average nontechnical user to understand.
Try sending math equations in plaintext and you'll quickly get the 'picture'. Yes, it can be done but it's also messy, time consuming and error prone.
Things that are noticeable about the promoters of plaintext: they're often programmers or those who are experienced in abbreviating messages, they talk in acronyms and understand complex concepts even though their presentation may be poor, and thus they've little interest in presentation for the sake of clarity.
Unfortunately, these attributes are so often what ordinary users lack and it's specifically why big companies such as Microsoft use HTML email. Making software easier is supposedly part of their plan even if they often screw these processes up during deployment.
Like you, I like HTML email, however I'm still critical of it for the reason that at this point in its development it still does not have sufficiently well developed formatting to do what I want to do. For instance, no email client is yet capable of inserting math equations into email with ease.
My philosophy about email is very simple: a user should be able to insert into a message any type of information that can be printed in a book or drawn or scribbled on paper by hand and it should be transmissible to the recipient without any loss of formatting. QED!
Right, we aren't there yet and this view is the antithesis of the plaintext philosophy. Nevertheless, that's what eventually will happen whether the plaintext-ers like it or not.
A final point: you'll note that plaintext-ers are always whingeing about users who cut-and-paste from word processors and web pages and that the info gets garbled in the process; well, they've a valid point.
However, this has nothing to do with the issue that email presentation and formatting should be as easy and as versatile as is possible. The fact that most email clients are woefully bad - in fact outright disgraceful - is a separate issue altogether.
Moreover, I'd suggest many mail clients would be in a much better state than they are at present if the plaintext-ers weren't sabotaging their development. After all, many of them have actually developed mail packages and they give little or no priority to HTML messages not to mention their fervent propaganda in favor of plaintext email.
__
Edit: this plaintext email story is not the only one to appear in the last day or so on HN about email content. The other, however, took a diametrically opposing view to this story as it discusses various ways of maintaining accurate CSS formatting in emails - now that's one hell of a jump from plaintext messages.
That story only demonstrates that the gap between the plaintext-ers and those who want advanced HTML formatting is as wide as ever. After reading it you'll likely realize that ultimately plaintext-ers will have very little chance of winning against strong commercial pressures that want better formatting within email.
The link below is to my comment and deals with many of the issues mentioned herein. Therein, I use Thunderbird to demonstrate some of the many problems with current email clients.
Incidentally, as that story was earlier I wouldn't be a bt surprised if this plaintext one was posted as a countermeasure to the former.
Some companies have given up on plain text completely. I'm getting these kind of messages now:
We have tried to send you this email as HTML (pictures and words) but it wasn't possible. In order for you to see what we had hoped to show you please click here to view online in your browser:
<long-url-with-lots-of-tracking-guids>
Ironically in this case the HTML message they so dearly hoped I'd see is only a notification that there is an update and I should go to the website and login to see what the update is. To top it off, the only picture in the message is the company's logo.
The worst part of those is that most of the time the HTML isn't even HTML. It's encoded in some some sort of weird email-html-specific content type. Base64 if you're lucky. Something far more obscure and email-html specific if you not.
When that happens I then have to copy the raw encoded "text" into some shady website $email-html-specific-content-type to text converter just to get the html in it's natural character set to manually find and copy the <long-url-with-lots-of-tracking-guids>.
This sounds great until you realize that, in the real world, people want to have some options to format the text they write (italics, bold, hyperlinks and the like), and there's absolutely nothing wrong with that.
In the real world, people want to have their company logo, nine image links to their social media accounts, and a special font for their signature.
Then they top post their entire email to a 257 email chain, so you have to do a kind of inverted scavenger hunt in order to figure out what they're talking about, none of which is improved or aided by the company logo, special font, or image links to nine different social media accounts.
And I haven't even gotten to grandma's love of emojis to convey her appreciation of your ribald joke about cookies.
Email is a tool, and like all tools, it can be grossly misused and abused.
Including, apparently, the people who created the web site, and who use bold text and different font sizes to format the headlines, colors to indicate features which are supported and not supported, and an image of a "plaintext certified" stamp.
I blame HTML email on the old UNIX neckbeards who hated on this kind of thing. If they had just given us the reasonable stuff, the industry wouldn't have had to resort to awful hacks.
It takes HTML as input and generates markdown-esque plaintext, with the main focus being to make the plaintext version easy and pleasant to read for human beings. Then using MIME types*, you transmit both the rich html version alongside the generated text/plain version.
This is cool because it makes it easy to respect both rich clients (like Gmail et. al.) as well as command-line or other clients which work better with simple text.
Hope this helps folks have the best of both worlds! :) cheers
* n.b. To ensure this works properly, be sure to use the right MIME headers:
I'm definitely a bit of a curmudgeon when it comes to email. Email is about communication and html gives people tools that they mostly use to make communication harder, not easier. For me, I prefer plain text email when I can get it. The main issue for me is that most of the uses of html email I see simply do not increase the utility of the email from the reader's perspective.
Large signatures don't communicate anything useful to me that isn't in the email header. The phone number can be nice, but you didn't need html for that. Your brand identity that takes up half a page (more since I keep email in a small window to the side of my monitor) does nothing other than obscure the content of the email. Trust me, sending me an intensely formatted email with lots of pictures does not increase the likelihood of me doing business with you.
99% of email I receive contains < 1 paragraph of useful information. I would prefer if people just sent that. Then I can read it quickly (since it uses the same font as everything else, not that faux handwriting font you found somewhere and thought looked great) and respond quickly and helpfully, which I hope was the purpose you sent the email in the first place.
There's probably a 1% where a nicely formatted document with graphs and images and headers are helpful. But you can just attach a document to the email if you're going to put that kind of effort it.
HTML is what killed email. The younger generation hates email in part because they associate email with spam, and spam email only became a large business because of HTML email. Plain text email could not easily be used for advertising, nor did plain text email support clever, manipulative tricks, like embedding hidden images so as to track people without them being aware of being tracked. Also, HTML email was implemented without enough thought as to the security and privacy problems it allowed, and it took 20 years to lock down HTML email to limit the damage to security and privacy. Plain text email was a great communication technology, and fairly immune to spam. I've often thought we should re-launch plain text email as some new, separate protocol. A wider demographic would be willing to communicate with plain text email, just as a wider demographic is comfortable with text messages on their phones.
Spam heavily uses styling and formatting features of HTML.
Similarly, paper advertising uses a lot of color and glossy paper.
Saying that HTML killed email is like saying glossy and colorful print killed books.
Tracking bugs in images is what killed HTML in email. For my security and privacy I have to block all external content by default. This means I get a ton of marketing emails that are either blank or missing the important bits unless I choose to load the external content.
The end result is that they almost always get trashed unread. I might actually be missing out on a useful new product or a great deal but I'm not going to bother with the extra clicks and unknown risks because marketing wanted to make it pretty over making it accessible.
A fancy ad in a magazine (not a book, of course) won't send you 2,000 pieces of advertising mail if you look at. An ad in a magazine won't empty your checking account if you write your phone number in another ad on the page.
Plain text is plainly unusable for a significant amount of people. Mobile? Have fun with a small font size to accommodate 80 chars. Ultra-wide? Same flowing problems. Right to Left language? Learn to 'work' with zero-width characters or you're SOL. Want to give more data to screen readers (sometimes the table is actually a table)? Hah.
Some people need to understand there are more use cases to email than mailing lists and that the 90s aren't coming back.
Changing the content type to include format=flowed means you're not sending plain text anymore. The content is some lightweight markup that's compatible with renderers that only understand plain text. This may seem pedantic, but it leads to real-world usability issues when folks with noncompliant MUAs quote or forward your flowed email; noncompliant meaning compliant with every standard except the one RFC that introduces format=flowed that isn't linked by the other RFCs one follows when writing an MUA, which makes sense since this is a one-off hack introduced by Eudora engineers and haphazardly implemented by some desktop clients.
If your display device can't even handle 80 column monospaced text then you need another display device.
There is nothing special about a smart phone that should prevent the display of the most basic format there is. The problem is with the email client...
Readit News
Inline images are a huge, huge advantage, especially for internal business communications where an email may be the only real documentation of a problem and its solution. (Or at least the only documentation that can stand on its own -- the alternative is usually a PowerPoint deck with missing information that was only given in a one-time presentation.) Being able to add a graph or a table or a schematic or a photo is important for anyone who works with non-text data. I suspect some programmers may be unaware of how unusual it is to work entirely in text.
For example, my workplace no longer allows forwarding or IMAP access because of this, so I'm forced to use the sh*tty Outlook web client, which wastes untold numbers of minutes each day waiting on the damn thing to load something. Just now it wouldn't let me open a PDF in a native client, because I guess Microsoft is so obsessed with locking us into their ecosystem. Instead I had to save it to disk first then go to the file manager to load it. (Yo, MSFT, this is why people hate you.)
Deleted Comment
Tl;dr a multipart message can include an image with an inline 'content disposition'. It's intended that clients show it inline, but I suspect many don't. Like I said I haven't received any yet anyway, so it's probably not that consequential.
Another quirk I'm aware of, by implementing my client quite unforgivingly, is that many emails are structured with the attachments only 'tied' to one alternative, often the text/plain media type, so if you interpret the parsed tree structure of alternatives/attachments literally, the HTML-formatted message might refer to an attachment (I mean a PDF say, not an embedded image) that's actually only available on the plaintext version. Having never encountered this before, I'm pretty sure other clients (like Gmail, Fastmail) present all found attachments alongside whichever alternative is viewed, not taking the actual email too literally (as I presently do).
I think it's significant that this is written in the passive voice. Because written this way it has the semblance of officialness, of generalness. Whereas writing it in the active voice would reveal that the people doing the preferring are just the people who made this website, and this preference is just that: a preference.
I love HTML emails, because I use italics basically all the time in my writing, and underscores _just don't offer the same experience_.
https://www.rfc-editor.org/rfc/rfc1896
> "Plaintext Certified" graphic by Jens
[1]: https://git.sr.ht/~sircmpwn/useplaintext.email
[2]: https://sourcehut.org
Deleted Comment
Deleted Comment
I agree with you. Moreover, there's very little chance of any agreement about this in the foreseeable future. Those who believe that plaintext is God's gift to emailers will never change their views. They've held these views for many decades, so there's precious little chance of them doing so anytime soon.
We've seen this all before in many other endeavors both technical and nontechnical. Those who wrote with quills and fountain pens said that writing would go to the dogs if ballpoint pens became commonplace.
Fortran programmers resisted going from upper to lowercase (even now, this modern browser editor has a hangover from that long gone era as it automatically converted 'Fortran' to uppercase as was the once custom). As a longtime Fortran programmer, I'd suggest that if decisions about the human-computer interface were left to my kind then we'd likely still be using uppercase ASCII and telex machine would still be fashionable although perhaps considerably faster.
As is usually the case, there's often some truth to the arguments and promoters of a cause buttress them up with historical usage or precedent so as to strengthen their case. Making their arguments sound credible is an essential part of convincing neophytes and potential converts that they're right.
I'll briefly go back to the fountain pen example for a moment as it's analogous to this case and it's simple and easy to understand. There's considerable evidence that when the ballpoint pen overtook nibbed pens a little after WWII that writing did in some ways go to the dogs but the ballpoint only shares part of the blame, things were much more complex than it alone.
I have some authority in saying that as I'm a regular user of fountain pens and I own quite a number of them. Moreover, my writing is much less sloppy with them than when I use ballpoints not to mention the fact that I actually prefer writing with a nib as it provide much better haptic feedback than do ballpoints. There's little argument about that and the evidence is easily demonstrated by examining the writing of current users of said pens.
That said, that's only part of the story. There are also other reasons for why writing deteriorated at that time but it's off topic so I won't go into specifics. However, the relevant point with this example is that the promulgators of nibbed pens only promote their benefit - that of better handwriting. What they omit and never tell you about are the many disadvantages that nibbed pens have: ink gets everywhere, they're messy and time consuming to fill even when using ink cartridges - and probably the worst of all: take a fountain pen on a plane trip and the reduced air pressure forces ink out and all over one's shirt pocket. Right, there couldn't be a worse place for that to happen. And it happens frequently (I know from experience).
Back to plaintext email, it's what its promoters do not tell you about that's the real problem. The list is long but there's little point detailing them all here except to say that two stand out. If images and tables cannot be included as inline information then either they're likely to be lost or misplaced and second, that having to encode and transmit them separately by other means is both time consuming and error prone even if done within the same email client.
Moreover, plaintext doesn't have the range of glyphs and or the means of displaying them so that the presentation of the message information is simple and easy for the average nontechnical user to understand.
Try sending math equations in plaintext and you'll quickly get the 'picture'. Yes, it can be done but it's also messy, time consuming and error prone.
Things that are noticeable about the promoters of plaintext: they're often programmers or those who are experienced in abbreviating messages, they talk in acronyms and understand complex concepts even though their presentation may be poor, and thus they've little interest in presentation for the sake of clarity.
Unfortunately, these attributes are so often what ordinary users lack and it's specifically why big companies such as Microsoft use HTML email. Making software easier is supposedly part of their plan even if they often screw these processes up during deployment.
Like you, I like HTML email, however I'm still critical of it for the reason that at this point in its development it still does not have sufficiently well developed formatting to do what I want to do. For instance, no email client is yet capable of inserting math equations into email with ease.
My philosophy about email is very simple: a user should be able to insert into a message any type of information that can be printed in a book or drawn or scribbled on paper by hand and it should be transmissible to the recipient without any loss of formatting. QED!
Right, we aren't there yet and this view is the antithesis of the plaintext philosophy. Nevertheless, that's what eventually will happen whether the plaintext-ers like it or not.
A final point: you'll note that plaintext-ers are always whingeing about users who cut-and-paste from word processors and web pages and that the info gets garbled in the process; well, they've a valid point.
However, this has nothing to do with the issue that email presentation and formatting should be as easy and as versatile as is possible. The fact that most email clients are woefully bad - in fact outright disgraceful - is a separate issue altogether.
Moreover, I'd suggest many mail clients would be in a much better state than they are at present if the plaintext-ers weren't sabotaging their development. After all, many of them have actually developed mail packages and they give little or no priority to HTML messages not to mention their fervent propaganda in favor of plaintext email.
__
Edit: this plaintext email story is not the only one to appear in the last day or so on HN about email content. The other, however, took a diametrically opposing view to this story as it discusses various ways of maintaining accurate CSS formatting in emails - now that's one hell of a jump from plaintext messages.
That story only demonstrates that the gap between the plaintext-ers and those who want advanced HTML formatting is as wide as ever. After reading it you'll likely realize that ultimately plaintext-ers will have very little chance of winning against strong commercial pressures that want better formatting within email.
The link below is to my comment and deals with many of the issues mentioned herein. Therein, I use Thunderbird to demonstrate some of the many problems with current email clients.
Incidentally, as that story was earlier I wouldn't be a bt surprised if this plaintext one was posted as a countermeasure to the former.
https://news.ycombinator.com/context?id=32807489.
Dead Comment
We have tried to send you this email as HTML (pictures and words) but it wasn't possible. In order for you to see what we had hoped to show you please click here to view online in your browser:
<long-url-with-lots-of-tracking-guids>
Ironically in this case the HTML message they so dearly hoped I'd see is only a notification that there is an update and I should go to the website and login to see what the update is. To top it off, the only picture in the message is the company's logo.
When that happens I then have to copy the raw encoded "text" into some shady website $email-html-specific-content-type to text converter just to get the html in it's natural character set to manually find and copy the <long-url-with-lots-of-tracking-guids>.
To make maters worse, there's now AMP for email, https://amp.dev/about/email/
Then they top post their entire email to a 257 email chain, so you have to do a kind of inverted scavenger hunt in order to figure out what they're talking about, none of which is improved or aided by the company logo, special font, or image links to nine different social media accounts.
And I haven't even gotten to grandma's love of emojis to convey her appreciation of your ribald joke about cookies.
Email is a tool, and like all tools, it can be grossly misused and abused.
2. The bloat/ugliness argument could also be applied to websites, but no one is out there advocating for plain text websites.
> "But if plaintext is so good, why is this page written in HTML?"
> This is a reference document, not an email, you twit.
https://github.com/jaytaylor/html2text/
https://jaytaylor.com/html2text
It takes HTML as input and generates markdown-esque plaintext, with the main focus being to make the plaintext version easy and pleasant to read for human beings. Then using MIME types*, you transmit both the rich html version alongside the generated text/plain version.
This is cool because it makes it easy to respect both rich clients (like Gmail et. al.) as well as command-line or other clients which work better with simple text.
Hope this helps folks have the best of both worlds! :) cheers
* n.b. To ensure this works properly, be sure to use the right MIME headers:
https://stackoverflow.com/questions/3902455/mail-multipart-a...
Now whatever the receiver decides they want to view they can.
Large signatures don't communicate anything useful to me that isn't in the email header. The phone number can be nice, but you didn't need html for that. Your brand identity that takes up half a page (more since I keep email in a small window to the side of my monitor) does nothing other than obscure the content of the email. Trust me, sending me an intensely formatted email with lots of pictures does not increase the likelihood of me doing business with you.
99% of email I receive contains < 1 paragraph of useful information. I would prefer if people just sent that. Then I can read it quickly (since it uses the same font as everything else, not that faux handwriting font you found somewhere and thought looked great) and respond quickly and helpfully, which I hope was the purpose you sent the email in the first place.
There's probably a 1% where a nicely formatted document with graphs and images and headers are helpful. But you can just attach a document to the email if you're going to put that kind of effort it.
The end result is that they almost always get trashed unread. I might actually be missing out on a useful new product or a great deal but I'm not going to bother with the extra clicks and unknown risks because marketing wanted to make it pretty over making it accessible.
Unlike email.
Some people need to understand there are more use cases to email than mailing lists and that the 90s aren't coming back.
In short, I completely agree with you.
On the other hand, humanity would probably be better served by moving toward semantic representation instead of fiddling in the deck over txt vs html.
Whoever said the column width has to be 80 chars everywhere?
There is nothing special about a smart phone that should prevent the display of the most basic format there is. The problem is with the email client...