Use plain-text email(useplaintext.email)
useplaintext.email
Use plain-text email
https://useplaintext.email/
205 comments
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.)
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.
> [...] 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.
Strange... IMAP isn't the opposite of Outlook. And using IMAP-based email client keeping data locally is a better choice than to use webmail and to rely on email storage services of mail provider.
Strange... IMAP isn't the opposite of Outlook. And using IMAP-based email client keeping data locally is a better choice than to use webmail and to rely on email storage services of mail provider.
Yeah, even if outlook manages to stay online the vast majority of the time having a local backup is extremely useful. I use IMAP with Thunderbird which stores mail in MBOX format which I find very helpful for searching or pulling data from too. Having to depend on webmail would feel so limiting!
Try Davmail, bit slow, but better than nothing
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.
This has been bugging me more and more recently - the assumption that if I've copied a few words from one app then pasted it into another it means I want to preserve all the formatting is wrong 99% of the time, yet there are now popular web-based apps (Confluence being one example from memory) that don't even support "paste as plain text". Actually what I typically want is "smart paste" which implies preserving changes in the formatting, and supporting e.g. hyperlinks etc., but ignoring whatever formatting attributes happened to be active at the beginning of the selection. But I'd rather lose support for rich text paste entirely over the situation we have now.
Ctrl+shift+v works most places to paste without formatting.
Agreed. I typically copy whatever text and paste it in the address bar and copy it again to lose the formatting. It also loses any line breaks but still worth it.
I keep a simple text editor open to accomplish that with. You keep line breaks that way.
That's my usual trick too but it's a terrible hack. Windows in general (I don't think MacOS is better) is crying out for more sophisticated built-in clipboard support, including supporting multiple active items (3's probably sufficient), and better conversion/formatting options (even to the point of automatic OCR etc.).
I was so happy when I figured that chrome based browsers now have a "Paste as plain text" functionality. I receive technical problem descriptions in (of course) HTML email formats, and copy pasting them into the archive systems web interface (which ofc is also rich text based) always was a PITA.
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.
You can send a plain text with attachments? That's how I used to do it (1996-2022)
I think the keyword there is "inline."
Many e-mail clients display the photos attached to plain text e-mail messages as "inline", you do not need a HTML message for that.
So how do I put text between them?
While this is something that I do not remember using, because I typically attach all the pictures at the end of the message, all the e-mail clients that I have used have 2 menu options while composing a plain text message: "Insert file" and "Attach file".
I believe that "Insert file" should insert a picture in the middle of the plain text, unlike "Attach file".
I believe that "Insert file" should insert a picture in the middle of the plain text, unlike "Attach file".
For that I think you have to use text/html so that you can reference the inline image's Content-ID. The rest of the 'HTML' could be plaintext of course, just needed for the <img>. You could also have related text/plain and text/html only for wherever you need the image - but support of that is probably even patchier than inline attachments.
Send your formatted document with embedded images as an attachment.
You could even send it as an HTML document, and if your email client supports it, it could display the document right in the client!
[deleted]
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).
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).
"[Plain-text email] is strongly preferred"
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_.
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.
https://www.rfc-editor.org/rfc/rfc1896
https://www.rfc-editor.org/rfc/rfc1896
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.
Slashes have the problem of being notation used for the IPA. So if you dabble in linguistics like I do. That might be a problem.
Since IPA uses a lot of unicode characters, would it be that much of a problem? IPA, imo, usually has a very specific look to it that wouldn't be confused with "normal" text.
It wouldn't be that much of a problem, but I think there's enough room for confusion, that I think people just wouldn't bother with it. For example, while it would be obvious that /tiθ/ is "teeth", something like /bad/ could be "bad" emphasized, or "bod". It wouldn't be that hard to disambiguate, but it is a little extra strain on the reader.
Most of the time, italics aren't actually all that important though, and could easily be replaced with other linguistic features.
Edit, another thing is that the slashes is actually graphemic notation, not phonetic. There's no reason that you have to use something modeled off the IPA there, it's just common to do so. You could use any alphabet.
Most of the time, italics aren't actually all that important though, and could easily be replaced with other linguistic features.
Edit, another thing is that the slashes is actually graphemic notation, not phonetic. There's no reason that you have to use something modeled off the IPA there, it's just common to do so. You could use any alphabet.
[deleted]
What is "the IPA"? Is that "the International Phonetic Alphabet"?
https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...
That would be my wager. In particular, it seems they're talking about the / ... / notation described in the first table here: https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...
[deleted]
This. It's interesting that there is nothing about the authors mentioned anywhere except:
> "Plaintext Certified" graphic by Jens
> "Plaintext Certified" graphic by Jens
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.
[1]: https://git.sr.ht/~sircmpwn/useplaintext.email
[2]: https://sourcehut.org
[1]: https://git.sr.ht/~sircmpwn/useplaintext.email
[2]: https://sourcehut.org
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.
[deleted]
[deleted]
"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.
https://news.ycombinator.com/context?id=32807489.
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.
quasarj(1)
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.
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>.
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>.
Do you mean https://en.wikipedia.org/wiki/Quoted-printable ? Since its a transfer encoding, the email client needs to decode it before rendering it. Its comparable to HTTP chunking.
Ah, so not directly HTML's fault. Thanks.
It's just the confluence of Quoted-printable transfer encoding and the tendency for HTML emails to embed links split up and in non-href and other tags that end up not getting rendered on my thunderbird fork in text mode which means I have to view source and deal with the Quoted-printable URLs.
It's just the confluence of Quoted-printable transfer encoding and the tendency for HTML emails to embed links split up and in non-href and other tags that end up not getting rendered on my thunderbird fork in text mode which means I have to view source and deal with the Quoted-printable URLs.
I think you need to patch your client to decode that, in the same vein it needs to be able to decode base64-encoded bodies.
This is the way. When I got an newsletter email, I quick scan for its blog link immediately and go to read it on website.
> Some companies have given up on plain text completely. I'm getting these kind of messages now
To make maters worse, there's now AMP for email, https://amp.dev/about/email/
To make maters worse, there's now AMP for email, https://amp.dev/about/email/
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.
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.
1. Emojis are perfectly supported in plain text as long as you’re using Unicode.
2. The bloat/ugliness argument could also be applied to websites, but no one is out there advocating for plain text websites.
2. The bloat/ugliness argument could also be applied to websites, but no one is out there advocating for plain text websites.
People who use screen readers would probably be very supportive of plain text Web sites. Web devs usually do a lot of work to make a Web site accessible.
In any event, email and Web sites are completely different things. Different communication mediums require different communication styles. Advocating for a certain style on one does not mean you have to also advocate for the same on another. The question would be "does rich-formatted text substantially add to the medium of email," and I think the clear answer to that is "not really."
An example of a good use of rich-formatted text contributing to an email would be coloring responses to questions. I see this one a lot, e.g. "my responses are in RED." We had the > quote style for this already, which was pretty good until an email thread started to get really, really deeply nested. In plain-text, at some point, somebody would have to edit the quotes down. There was a marginal advantage to having styled text to clear this up. Was this advantage enough to have to suffer through the majority of emails where this was not required and the formatted text was rife with extraneous or useless widgets?
In any event, email and Web sites are completely different things. Different communication mediums require different communication styles. Advocating for a certain style on one does not mean you have to also advocate for the same on another. The question would be "does rich-formatted text substantially add to the medium of email," and I think the clear answer to that is "not really."
An example of a good use of rich-formatted text contributing to an email would be coloring responses to questions. I see this one a lot, e.g. "my responses are in RED." We had the > quote style for this already, which was pretty good until an email thread started to get really, really deeply nested. In plain-text, at some point, somebody would have to edit the quotes down. There was a marginal advantage to having styled text to clear this up. Was this advantage enough to have to suffer through the majority of emails where this was not required and the formatted text was rife with extraneous or useless widgets?
> People who use screen readers would probably be very supportive of plain text Web sites.
I beg to disagree. Plain text doesn't offer any support for embedded metadata, which are vital for screen readers. With just plain text you have no way to tell apart a header, footer or aside from the main content.
> Web devs usually do a lot of work to make a Web site accessible.
Yes, they do a lot of work. Mostly using semantic HTML and embedding text descriptions in data attributes.
This should go without saying: Plain text is less accessible than well written, semantic HTML, not more.
I beg to disagree. Plain text doesn't offer any support for embedded metadata, which are vital for screen readers. With just plain text you have no way to tell apart a header, footer or aside from the main content.
> Web devs usually do a lot of work to make a Web site accessible.
Yes, they do a lot of work. Mostly using semantic HTML and embedding text descriptions in data attributes.
This should go without saying: Plain text is less accessible than well written, semantic HTML, not more.
"my responses in red" assumes a lot about the visual abilities of the reader. I'm sure there's a better way to express this idea.
> no one is out there advocating for plain text websites.
The gemini folks (gemini.circumlunar.space/) basically are, but I think it's a similarly niche / reactionary take.
The gemini folks (gemini.circumlunar.space/) basically are, but I think it's a similarly niche / reactionary take.
Yeah but we wouldn't want to cripple it for everyone because there exist some people who abuse it.
This is a strawman. How does plain text stop people abusing a medium?
Their argument is that by not having HTML, people can no longer annoy with their use of HTML.
This is a client-side issue, IMO. If someone doesn't like HTML, simply don't enable parsing of it and view the source.
This is a client-side issue, IMO. If someone doesn't like HTML, simply don't enable parsing of it and view the source.
People can annoy with plain words just as well.
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.
It's a bit rude for HN, but from the bottom of the article,
> "But if plaintext is so good, why is this page written in HTML?"
> This is a reference document, not an email, you twit.
> "But if plaintext is so good, why is this page written in HTML?"
> This is a reference document, not an email, you twit.
It seems their main point is using HTML is trading accessibility and security concerns for prettification. Why is a reference document an acceptable trade off of accessibility and security concerns for prettier formatting but a personal email isn't?
They could have made this site plain text and followed all of their own guidelines, but they didn't. Instead, they wanted to make the site look prettier to get their message across with additional formatting plain text can't handle. They're reducing accessibility and increasing security issues just for their own superfluous desires.
They could have made this site plain text and followed all of their own guidelines, but they didn't. Instead, they wanted to make the site look prettier to get their message across with additional formatting plain text can't handle. They're reducing accessibility and increasing security issues just for their own superfluous desires.
Well, this reference document seems to work reasonably as plain text. What’s that person’s excuse for html just because it moves via HTTP?
https://www.rfc-editor.org/rfc/rfc5322.txt
https://www.rfc-editor.org/rfc/rfc5322.txt
Plain text with 80-column line breaks suuuuucks on mobile. Give me HTML any day of the week.
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.
The foolishness of that comment is revealed when one learns that Nathaniel Borenstein of Bellcore gave you the text/enriched content type in 1993.
Years ago I made a Go library called `html2text' just for this:
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...
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...
Yep, I do similar with all emails I send, run the html through a `html2text` transformer and attach that as the plaintext variant of the email.
Now whatever the receiver decides they want to view they can.
Now whatever the receiver decides they want to view they can.
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.
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.
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.
Do you really think you might get great deals by reading emails that you did not ask for? Just remember that the one who sent you the email did it for their own profit. So it's a good thing you thrash them. Most such emails have an unsubscribe link that works. If not, simply mark them as spam.
So far for the filtering.
The rest of the emails most likely contain good communication with people you know, who mostly do not bother adding bitmaps in their signature; but they might use other paragraph options like bold, italics, in-line photographs or diagrams, code snippets in monospaced font or other features that make the email more readable or informative.
So that is why i do not agree with 'html killed email'.
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.
Unlike email.
Unlike email.
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.
Some people need to understand there are more use cases to email than mailing lists and that the 90s aren't coming back.
80 char wrapping is solved by format=flowed. However none of the popular providers seem to implement it.
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.
In short, I completely agree with you.
In short, I completely agree with you.
Yes, a lot of the “problems” of plain text boil down to poor authoring/rendering tools.
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.
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.
> Mobile? Have fun with a small font size to accommodate 80 chars.
Whoever said the column width has to be 80 chars everywhere?
Whoever said the column width has to be 80 chars everywhere?
Not uncommonly, the provider/program through which the email was sent.
It's really amusing how people addicted to rich text assume plain text suffers the same limitations.
Then it will just contain extra line breaks, but the mobile MUA reading it will reflow it just fine.
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...
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...
I'm a huge proponent of text/plain.
There was a long-ish thread on the mutt mailing list recently, which open my narrow mind a bit. Html formatted mails are not a question of personal preference. Exchanging Mails with other people also includes supporting their way of dealing with mails.
So since a long time I convert text/html to plain text in order to be able to read that. Since recently, I also send a simple multipart mail with both text/plain and text/html. The conversion script it a simple 10 lines python markdown script. All done and all happy.
In particular, it makes my mail more readable on any kind of display; e.g. narrow phone or wide monitor.
I'm still happy to converse only via text/plain, like here.
There was a long-ish thread on the mutt mailing list recently, which open my narrow mind a bit. Html formatted mails are not a question of personal preference. Exchanging Mails with other people also includes supporting their way of dealing with mails.
So since a long time I convert text/html to plain text in order to be able to read that. Since recently, I also send a simple multipart mail with both text/plain and text/html. The conversion script it a simple 10 lines python markdown script. All done and all happy.
In particular, it makes my mail more readable on any kind of display; e.g. narrow phone or wide monitor.
I'm still happy to converse only via text/plain, like here.
I love fangless manifestos like this, because they're usually right, and there's nothing better than a quixotic crusade. Here's the hill I'll die on: email works best when it's like a long-form SMS message.
As for the folks who go on about branded marketing emails… gawd, it's like hearing someone say "actually I wish I got more, better junk mail"
It's a pity that something like Markdown didn't exist back in the nineties. If we could just have had some really basic formatting options (bold, italics, and a couple images are not unreasonable requests), the whole scourge of HTML email might have been sidestepped.
As for the folks who go on about branded marketing emails… gawd, it's like hearing someone say "actually I wish I got more, better junk mail"
It's a pity that something like Markdown didn't exist back in the nineties. If we could just have had some really basic formatting options (bold, italics, and a couple images are not unreasonable requests), the whole scourge of HTML email might have been sidestepped.
Are there any other manifestos that you are particularly fond of?
I hear ya on Markdown.
I hear ya on Markdown.
https://realnames.online/
any search result for “considered harmful”
any search result for “considered harmful”
> HTML emails are mainly used for marketing
Whaaaaat? How about a more honest version...
> HTML emails are mainly used BY LITERALLY EVERYONE
Whaaaaat? How about a more honest version...
> HTML emails are mainly used BY LITERALLY EVERYONE
Not true. 90% of the emails I get from real people are plain-text. 100% of the emails I get from businesses are HTML. It makes it quick and easy to sort out a lot of the garbage.
That's weird. I'd say 90% of the emails I get from real people are from gmail which are 100% html. I don't know ANYONE that sends plain text emails tbh.
That's not a fair interpretation. Most people only want to send text for the most part, but are forced to send HTML via client defaults.
That's entirely false. "most people WANT to send text" .. nah most people literally don't care and are fine with the html default, and occasionally use bold or italics or images, and they would probably complain if they suddenly couldn't.
This is the true answer, everyone uses them and that battle has been lost years and years ago.
The effort should be fought in adding a newer way of doing HTML email that is better, and finally kill that damn IE 6-based renderer used by Outlook. Curse that thing.
The effort should be fought in adding a newer way of doing HTML email that is better, and finally kill that damn IE 6-based renderer used by Outlook. Curse that thing.
Yes, this. Also, any good email client will strip out the graphics and just give you formatted text anyway. I use Fastmail's web interface and there's a "Load Images" button but I rarely click it. Best of both worlds.
Know your audience.
I default to plain-text 99% of the time. In my corporate world I am FORCED to embed excel tables, colour-coded replies (Bob's replies are in RED, Alice's replies are in GREEN) [fuck the colour blind].
And I hate it. So it's only those emails that get it. I have been forced to conform. Outlook is still configured for plain-text email, and bitches about it whenever possible.
Everywhere else, plain-text only. Resistance is futile.
I default to plain-text 99% of the time. In my corporate world I am FORCED to embed excel tables, colour-coded replies (Bob's replies are in RED, Alice's replies are in GREEN) [fuck the colour blind].
And I hate it. So it's only those emails that get it. I have been forced to conform. Outlook is still configured for plain-text email, and bitches about it whenever possible.
Everywhere else, plain-text only. Resistance is futile.
The real problem with HTML emails is inconsistent rendering by different email clients. I had to make some HTML email templates for a marketing campaign, thought it would be easy seeing as I make HTML website template all day.... ended up spending hours debugging random Microsoft Outlook rendering inconsistencies and other client issues.
Some clients don't support anything but inline styles, others support style tags. Some support media queries, some don't. Some support custom fonts / web fonts, some don't. Gmail in browser behaves differently from Gmail android client behaves differently from Gmail iOS client, etc. There's an absolutely infuriating dark mode on Outlook that randomly swaps certain color hues and as far as I can tell there's no way to detect or show different styles for it, you just have to make your design stand up to certain colors being swapped (don't use any logo or other image that can't stand clearly against both black and white backgrounds). I learned a lot about a bunch of extremely legacy HTML and CSS rules that would never be used in a modern website but were basically required for a semi-responsive email.
I won't ever do it again- if I need a custom styled email, I'll use someone else's template or email template builder service.
Some clients don't support anything but inline styles, others support style tags. Some support media queries, some don't. Some support custom fonts / web fonts, some don't. Gmail in browser behaves differently from Gmail android client behaves differently from Gmail iOS client, etc. There's an absolutely infuriating dark mode on Outlook that randomly swaps certain color hues and as far as I can tell there's no way to detect or show different styles for it, you just have to make your design stand up to certain colors being swapped (don't use any logo or other image that can't stand clearly against both black and white backgrounds). I learned a lot about a bunch of extremely legacy HTML and CSS rules that would never be used in a modern website but were basically required for a semi-responsive email.
I won't ever do it again- if I need a custom styled email, I'll use someone else's template or email template builder service.
Thanksfully, you are not alone, and lots of these cuts have been codified into best practices...and published as guides by the big players in the email marketing world (e.g. mailchimp, campaign monitor, etc.). If/Whenever you need to work in this area, just look up one of those guides from those established players and follow their lead...better yet, grab one of their templates when they offer them. In addition, as @cygned has noted, there are even some "meta languages" (like MJML and many others) created by these same big email providers that serve to do away with some of the more annoying parts of crafting email templates. Of course, i hope to never have to spend too muich time in creating templates for email....just too many nightmares from so many yearsplaying in this space! ;-)
Try MJML, works wonders
Don't. Your plain text email is going to render like shit in any modern mail client, and you are going to look like fool who can't write an email.
You should actually try this if you use plain text email - email yourself and try and read it in a normal mail client (gmail, outlook, etc) on a phone. You'll need to scroll horizontally to read the message.
Now read it on a normal desktop email client. You'll see a skinny tall column of text in a tiny font.
Now reply to a normal html email thread and view it in a normal mail client. Congrats - you've just broken the formatting for everyone* on the thread. Nobody wants you see those >> things all over the place.
I don't know why this idea persists. Nobody wants to read a book in a fixed width font, nobody wants to read a web page in a fixed width font that doesn't adapt to your viewport size, etc. Hell, programmers even want colors and fancy formatting in their source code.
Plain text email is the ham radio of the internet. If you are an email hobbiest and you enjoy sending and receiving plain text emails to other hobbiests more power to you. But don't try and setup a meeting at work over your ham radio. You'll just look dumb.
You should actually try this if you use plain text email - email yourself and try and read it in a normal mail client (gmail, outlook, etc) on a phone. You'll need to scroll horizontally to read the message.
Now read it on a normal desktop email client. You'll see a skinny tall column of text in a tiny font.
Now reply to a normal html email thread and view it in a normal mail client. Congrats - you've just broken the formatting for everyone* on the thread. Nobody wants you see those >> things all over the place.
I don't know why this idea persists. Nobody wants to read a book in a fixed width font, nobody wants to read a web page in a fixed width font that doesn't adapt to your viewport size, etc. Hell, programmers even want colors and fancy formatting in their source code.
Plain text email is the ham radio of the internet. If you are an email hobbiest and you enjoy sending and receiving plain text emails to other hobbiests more power to you. But don't try and setup a meeting at work over your ham radio. You'll just look dumb.
> You should actually try this if you use plain text email - email yourself and try and read it in a normal mail client (gmail, outlook, etc) on a phone. You'll need to scroll horizontally to read the message.
OK, I just did. I didn't have any of those issues at all. Perhaps it depends on the exact mail client you use?
OK, I just did. I didn't have any of those issues at all. Perhaps it depends on the exact mail client you use?
I do wish more email clients could render markdown from a plaintext message (written with markdown syntax, of course).
Mozilla Thunderbird does that, with the older, pre-Markdown, internet-standard version.
Which also works in Facebook Messenger and in WhatsApp, which very few people seem to know.
Which also works in Facebook Messenger and in WhatsApp, which very few people seem to know.
I'm sorry, but searching the documentation (and the internet) is failing me - would you please provide an example or link? Thank you.
Blimey. People really won't take your word online these days.
OK, here, I made you a screenshot.
https://imgur.com/a/frml6cs
OK, here, I made you a screenshot.
https://imgur.com/a/frml6cs
I'd be extremely happy if markdown were the accepted way of applying formatting. It lacks almost all of the problems with formatting emails with HTML.
Agreed. Every time I've tried to switch to using plain text I always encountered cases where additional formatting made my message easier to read and understand.
I'd be perfectly happy with Markdown or likely RFC 1896 as someone else mentioned.
I'd be perfectly happy with Markdown or likely RFC 1896 as someone else mentioned.
Formatted text is less accessible. Accessibility is a legal requirement in many countries; in the UK it has been a legal requirement for twelve years.
https://info.webusability.co.uk/blog/what-is-the-law-on-acce...
Formatted email is especially difficult for blind users, whether they are using a screen reader or a Braille display.
Formatting can't be read aloud via text-to-speech if a sighted person is using it on a smartwatch or similar.
Formatting does not survive automatic translation. I live in a country where I do not speak the local language and I rely very heavily on machine translation; in fact in the last 5min I have just paid my gas bill using Google Translate to understand the email I was sent, and then again to navigate the gas supplier's website.
Formatting does not display in on-screen notification messages, and it may not survive being forwarded, read in certain clients, etc.
If you find you are relying on it, then you should improve your writing skills, because you are unwittingly excluding people and some will receive damaged versions of your emails which they can't understand correctly.
https://info.webusability.co.uk/blog/what-is-the-law-on-acce...
Formatted email is especially difficult for blind users, whether they are using a screen reader or a Braille display.
Formatting can't be read aloud via text-to-speech if a sighted person is using it on a smartwatch or similar.
Formatting does not survive automatic translation. I live in a country where I do not speak the local language and I rely very heavily on machine translation; in fact in the last 5min I have just paid my gas bill using Google Translate to understand the email I was sent, and then again to navigate the gas supplier's website.
Formatting does not display in on-screen notification messages, and it may not survive being forwarded, read in certain clients, etc.
If you find you are relying on it, then you should improve your writing skills, because you are unwittingly excluding people and some will receive damaged versions of your emails which they can't understand correctly.
> Formatted text is less accessible.
Is this universally true? I'm not an accessibility expert but from working on a couple 508 projects it seems that formatting such as headings improves accessibility and makes navigation easier.
> If you find you are relying on it, then you should improve your writing skills
Some of the content I email includes screenshots of issues, photographs from studies, iconography, and data visualizations. Beyond ensuring that I include accompanying/alternate text I accept that these will not be accessible.
Other content includes hierarchical lists and snippets of tabular data. While these can be creatively emulated using plain text I find that people doing so typically resort to a jarring sort of ASCII-art approach that ends up being even less accessible than just using the proper semantic tags or markdown.
More broadly I find it disappointing that we ended up in this situation where technical constraints dictate what is good writing. Italics has been part of writing for hundreds of years and now it's relegated to "markup" because of decisions some computer engineers made sixty years ago. Can you imagine if the ASCII standard had stuck with the initial all-caps specification and relegated lowercase letters to be markup? Would we now be arguing that people who don't write in all caps "should improve [their] writing skills"?
Personally I prefer structured text to either plain or formatted text. Formats like markdown aren't perfect but they basically provide what I need so it's disappointing that email clients force us to choose between the extremes of plain text and HTML.
Is this universally true? I'm not an accessibility expert but from working on a couple 508 projects it seems that formatting such as headings improves accessibility and makes navigation easier.
> If you find you are relying on it, then you should improve your writing skills
Some of the content I email includes screenshots of issues, photographs from studies, iconography, and data visualizations. Beyond ensuring that I include accompanying/alternate text I accept that these will not be accessible.
Other content includes hierarchical lists and snippets of tabular data. While these can be creatively emulated using plain text I find that people doing so typically resort to a jarring sort of ASCII-art approach that ends up being even less accessible than just using the proper semantic tags or markdown.
More broadly I find it disappointing that we ended up in this situation where technical constraints dictate what is good writing. Italics has been part of writing for hundreds of years and now it's relegated to "markup" because of decisions some computer engineers made sixty years ago. Can you imagine if the ASCII standard had stuck with the initial all-caps specification and relegated lowercase letters to be markup? Would we now be arguing that people who don't write in all caps "should improve [their] writing skills"?
Personally I prefer structured text to either plain or formatted text. Formats like markdown aren't perfect but they basically provide what I need so it's disappointing that email clients force us to choose between the extremes of plain text and HTML.
I've been using MailMate[1] on MacOS, but I don't know any other email clients that render Markdown.
[1]: https://freron.com/
[1]: https://freron.com/
My email app _Mailtemi_ actually does HTML -> Markdown.
Still curious, is it worth going this direction?
I'm using Markdown for email preview, local search, etc. In the future I think about experimenting with voice mail. Something like "Read all important emails", which will skip all marketing, updates, or forums. Also I have an experimental feature email to be viewed always in Markdown.
I'm using Markdown for email preview, local search, etc. In the future I think about experimenting with voice mail. Something like "Read all important emails", which will skip all marketing, updates, or forums. Also I have an experimental feature email to be viewed always in Markdown.
Thanks for the tip, looks great i will definitely give it a try.
For €62, i wonder how often a new version arrives / i'll have to buy/upgrade again...
For €62, i wonder how often a new version arrives / i'll have to buy/upgrade again...
There are some valid reasons to avoid using HTML email (some of which are even listed on this page -- like avoiding link obfuscation), but my god does this page come off as condescending, right from the opening line ("Plain-text email is strongly preferred").
The reality is that HTML email's too convenient to go away at this point. It fills enough niches both in people's corporate and personal lives to ever truly be undone, and having so many of the recommended clients being TUI-based (and emacs-based, apparently) shows a particular tone-deafness since TUI mail clients will almost certainly never be widely-adopted ever again, even by people who spend lots of time in a shell. Add on to that, that TUI mail clients will almost invariably render monospace fonts, which aren't great for reading things other than code.
The reality is that HTML email's too convenient to go away at this point. It fills enough niches both in people's corporate and personal lives to ever truly be undone, and having so many of the recommended clients being TUI-based (and emacs-based, apparently) shows a particular tone-deafness since TUI mail clients will almost certainly never be widely-adopted ever again, even by people who spend lots of time in a shell. Add on to that, that TUI mail clients will almost invariably render monospace fonts, which aren't great for reading things other than code.
Its also incredibly condescending having them tell me I shouldn't format my message as HTML when the message they're using to tell me that is an HTML formatted message.
If plain text was more than acceptable to get the point across, this page wouldn't use HTML. Instead, they have an inline image, they have multiple font weights, anchor tags, inline styles, chosen fonts, changes in colors, hyperlinks, bulleted lists, etc.
If plain text was more than acceptable to get the point across, this page wouldn't use HTML. Instead, they have an inline image, they have multiple font weights, anchor tags, inline styles, chosen fonts, changes in colors, hyperlinks, bulleted lists, etc.
But they're two different media. It's like they're saying "writing in longhand is best" but you're complaining because they're using mass print media to spread the word. Or complaining because a book or movie is advertised on TV or in a newspaper.
Nearly all their arguments as to why prefer plaintext versus HTML apply for this media as well. Having this page as an HTML document instead of plain text increases security risks and can reduce accessibility.
They argue you do not need HTML formatting to get a point across, but then rely on HTML formatting to get their point across. Why did they bother using bulleted lists? Why did they use links and anchor tags instead of just having the URL written out in plain text? Why would they bother embedding an image into their page instead of just giving us the URL and letting us choose to fetch it if we wanted to after reading the message? Maybe because its better to look at and read using HTML formatting instead of just plain text.
Maybe I want a bulleted list in an email. Maybe I would like to have a link instead of just having a giant URL as plain text in my email. Maybe I'd like to have the image I'm talking about in my email in the email instead of being some other resource for the person to fetch. Its condescending for them to say "You should never use bulleted lists, here's a bulleted list of reasons why you shouldn't use bulleted lists!" Its condescending for them to say don't use links when they use loads of links. If its better to just put the full URL out there plainly, then they should have done it. They didn't because its not better, its nice using links.
If the alternative is perfectly acceptable, why didn't they just use the alternative? They didn't, because the alternative isn't perfectly acceptable all the time. There's a good reason to mark up your writing.
Its condescending for them to say:
> Rich text isn't that great, anyway
in a rich-text document. If rich text isn't that great, why are they using it? Because the alternative isn't that great!
They argue you do not need HTML formatting to get a point across, but then rely on HTML formatting to get their point across. Why did they bother using bulleted lists? Why did they use links and anchor tags instead of just having the URL written out in plain text? Why would they bother embedding an image into their page instead of just giving us the URL and letting us choose to fetch it if we wanted to after reading the message? Maybe because its better to look at and read using HTML formatting instead of just plain text.
Maybe I want a bulleted list in an email. Maybe I would like to have a link instead of just having a giant URL as plain text in my email. Maybe I'd like to have the image I'm talking about in my email in the email instead of being some other resource for the person to fetch. Its condescending for them to say "You should never use bulleted lists, here's a bulleted list of reasons why you shouldn't use bulleted lists!" Its condescending for them to say don't use links when they use loads of links. If its better to just put the full URL out there plainly, then they should have done it. They didn't because its not better, its nice using links.
If the alternative is perfectly acceptable, why didn't they just use the alternative? They didn't, because the alternative isn't perfectly acceptable all the time. There's a good reason to mark up your writing.
Its condescending for them to say:
> Rich text isn't that great, anyway
in a rich-text document. If rich text isn't that great, why are they using it? Because the alternative isn't that great!
There is no rationale given as to “why plaintext.” HTML can be much more expressive in a shorter amount of authoring time.
There is, it's further down the page: https://useplaintext.email/#why-plaintext
> Rich text isn't that great, anyway
proceeds to write a nearly 3,000 word document with rich formatting an inline images...
proceeds to write a nearly 3,000 word document with rich formatting an inline images...
Little known fact: a website and an email are different things.
What difference does that make? Their arguments are similar in both cases. HTML and embedded media increase security risks and can lower accessibility. Rich text isn't that great anyways, nobody needs it. Just use periods instead of bullet points. Why would anyone want to make different headings or make some text bold? Completely superfluous. Plain text should be all you need, in every medium.
Why should you bother using markup on a webpage? How do those reasons never apply to sending an email?
Why should you bother using markup on a webpage? How do those reasons never apply to sending an email?
Sure there is: https://useplaintext.email/#why-plaintext. (I don't agree with it, but it's there.)
I will rather use HTML email via standard federated email network and be able to put images inline with text captions describing these images, rather than being text only email purist and then having to bend over to send images with "inlined" text in silo apps like whatsapp, slack, signal or telegram.
I run into difficulties with text-wrapping in plain-text emails. If there are nested quotations, the wrapping can get jumbled, especially if reading on a small screen like a smartphone. Don't have that issue with html emails. Am I doing something wrong?
No, the specifics of making sure plain text email wraps correctly are just complex enough it might as well be html email. It's 2022, and in this day and age the concept of sticking to 80 columns of plain text is outdated and mostly reactionary.
I was keen to try out 100% pure plain text emails and ran into this problem too. The reading experience on mobile wasn't good, and that's increasingly where people are. Very spartan, minimal HTML resolves all the problems, but then you're back to HTML.
If all that was used was basic HTML formatting tags, I'd be fine with it. But that's not what it is.
Sure, but if there were enough motivation and interest from various broader communities (not just in email, but also security, say) maybe a "Gemini" style approach could work. I would be very happy for email to be limited to a Markdown-style subset of HTML.
You're not doing anything wrong, it's the people who insist on hard-wrapping emails they send are who's wrong.
I never allow HTML to render in my emails, for security purposes.
I've found it to be rather helpful in determining which emails to delete immediately. If it's HTML, it's probably commercial in nature, and if I can't easily read the contents in the HTML source, then it's certainly an email that isn't worth reading at all.
That said, email in general would be greatly improved if it were strictly plain-text.
I've found it to be rather helpful in determining which emails to delete immediately. If it's HTML, it's probably commercial in nature, and if I can't easily read the contents in the HTML source, then it's certainly an email that isn't worth reading at all.
That said, email in general would be greatly improved if it were strictly plain-text.
Previous discussion (341 comments):
https://news.ycombinator.com/item?id=20513987
https://news.ycombinator.com/item?id=20513987
Quincy Larson runs a 4 million subscriber list with plain text email https://www.freecodecamp.org/news/quincy-larson-5-links-wort...
"HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place."
Stops reading.
Stops reading.
To be fair, I can't think of the last time a human sent me an HTML email.
You mean HTML-only email?
No, an email that wasn't text/plain.
With multipart, every part has a separate mimetype. Your client will decide which one to show. https://en.m.wikipedia.org/wiki/MIME#Multipart_messages
Do you mean that there is a part that isn't text/plain ("HTML email") or that there is no part that is text/plain ("HTML-only email")?
Do you mean that there is a part that isn't text/plain ("HTML email") or that there is no part that is text/plain ("HTML-only email")?
I mean there is no HTML part.
Partly the reason I wrote and use this command line client for GMail: https://github.com/ThomasHabets/cmdg
I wonder if the point would have hit harder if the website was in plain text?
The phrase "supports bottom posting" isn't the best way to describe formatting replies. Good netiquette typically involves deleting quoted text you're not directly addressing in your reply and type your responses inline. That is:
Just quoting the entire original message and posting your reply at the bottom is as bad, if not worse, than just top posting.
> Quoted point 1
Response 1
> Quoted point 2
Response 2
Just quoting the entire original message and posting your reply at the bottom is as bad, if not worse, than just top posting.
No? The imperative tone doesn’t sway me. There are few and poor reasons to “strongly prefer” plaintext. It’s just an aesthetic and personality choice. Which almost no one does.
I love the idea of plain text email. But I don't think it works as well with a huge volume of mail most folks get.
As I create emails for customers and such I find some level of html / banner / something even beyond the subject is needed to help folks filter though all their emails.
In my experience emails with a company banner and large text indicating the reason for the email "your order has shipped" are spotted quickly by their customers / quickly understood / filtered easier.
As I create emails for customers and such I find some level of html / banner / something even beyond the subject is needed to help folks filter though all their emails.
In my experience emails with a company banner and large text indicating the reason for the email "your order has shipped" are spotted quickly by their customers / quickly understood / filtered easier.
Using the subject line to indicate the reason for the email isn't sufficient?
I’ll settle for text/enriched (RFC 1896). It’s the best of both worlds: The safety of plain text, but proportional fonts, flowing paragraphs, and text styling like HTML.
HTML is great when you deal with lots of email correspondence at work. The signatures and formatting make it easier to anchor memories and navigate conversations.
I'm willing to wiggle a bit here. Stop putting pictures and fixed width tables in your signatures at least...
> ...Stop putting pictures and fixed width tables in your signatures at least...
This is what i think of whenever i change employers, and/or they rebrand and need "everyone to come on and let's all update our email sigs together to support the brand!" ugh!
This is what i think of whenever i change employers, and/or they rebrand and need "everyone to come on and let's all update our email sigs together to support the brand!" ugh!
Fun bit of history: Jamie Zawinski thinks he may have invented html email while at Netscape [0].
[0] https://www.jwz.org/blog/2017/09/html-email-was-that-your-fa...
[0] https://www.jwz.org/blog/2017/09/html-email-was-that-your-fa...
It might be worth pointing out that JWZ doesn’t like HN and redirects any referrals to an interesting image, in case you were thinking of clicking on that directly instead of copying and pasting.
Maybe @dang should just change it so links to jwz.org aren't clickable? It would force us to copy-paste.
Why is it HN's job to fix someone else's breakage of the web's standard behavior?
It's not. But that doesn't mean we can't try to avoid the issue. For example, stores aren't required to use time delay safes (and other robbing counter-measures). After all, robbery is illegal, but they still probably should install them.
Eh, let people learn about JWZ's distaste for HN and the iconic picture of a hairy testicle in an eggcup. It's childish but harmless fun. The Internet has been sanitised enough already.
In the middle of an entirely different discussion[1] it more or less fell out that the problems associated with HTML emails would not be problems if we started treating unsigned/anonymous emails with some reasonable amount of suspicion. Letting any rando on the internet have access to your HTML interpreter doesn't seem reasonable and things are much better if you only allow that access to people you actually know.
HTML is not the only problem with email that would be lessened if we could finally get people to start signing their emails and start treating anonymous emails with suspicion...
[1] https://articles.59.ca/doku.php?id=pgpfan:no_new_ae (See the "A proposed alternative solution to EFAIL" section)
HTML is not the only problem with email that would be lessened if we could finally get people to start signing their emails and start treating anonymous emails with suspicion...
[1] https://articles.59.ca/doku.php?id=pgpfan:no_new_ae (See the "A proposed alternative solution to EFAIL" section)
Can you cite any major security breaches accomplished by HTML in email context? I'm talking HTML and not links. I think links should be banned in email, and you should be forced to copy and paste them to get to wherever you're going, it's too easy to hide the actual link with hypertext.
This ship sailed a very long time ago.
[deleted]
The primary argument I'm seeing against Plain Text Email is "But I like formatting!"
OK.
But there were probably better ways to achieve lightweight formatting options that didn't include "Let's embed a full web browser in our email client."
OK.
But there were probably better ways to achieve lightweight formatting options that didn't include "Let's embed a full web browser in our email client."
I had a BSD-geek friend whose area of specialty was in deploying and maintaining mail servers on that platform. He had always been an advocate for plain-text emails. He was also a single guy who had sex with his dog, so he wasn't emailing pictures to his grandma.
Personally, I think evolving email into HTML has always been a foregone conclusion regardless of the inconvenience it causes to an extreme minority. Plus, I like the convenience of sending photos to grandma and checking her email is all she has the aptitude for anyway.
Long live HTML mail!
Personally, I think evolving email into HTML has always been a foregone conclusion regardless of the inconvenience it causes to an extreme minority. Plus, I like the convenience of sending photos to grandma and checking her email is all she has the aptitude for anyway.
Long live HTML mail!
I really hope you meant "sex like a dog" or something with that anecdote.
I'd love to use mutt for my mail email client every day, but it's essentially impossible to use especially for work context without me risking missing important emails or having to spend way too much time fiddling with viewing html emails from other companies / coworkers in a reasonable fashion via the mutt TUI so unfortunately this isn't going to happen for me.
As a compromise, I have a key bound to open a web browser to read any html-only emails. I find it to be the best of both worlds.
First and foremost, I believe most of the issues can be addressed using a markup language like Markdown or similar. Accessibility clients can be updated to accommodate such formatting as part of the standard.
Second, hard wraps should not be mandatory and in fact discouraged. If someone wants 72 columns then there email client should be the one setting that, not the message itself.
Second, hard wraps should not be mandatory and in fact discouraged. If someone wants 72 columns then there email client should be the one setting that, not the message itself.
On a similar note, the ASCII Ribbon campaign:
http://www.asciiribbon.org
http://www.asciiribbon.org
Imagine trying to read that very website as a plain text email. The headers, bolding, and rulers make a huge difference.
Plain text email reminds me of the original ethos behind Markdown. "You're already doing it". Except, not everyone has the same rules. We can all read it but there becomes necessary a translation layer.
Plain text email reminds me of the original ethos behind Markdown. "You're already doing it". Except, not everyone has the same rules. We can all read it but there becomes necessary a translation layer.
If I’m not phishing or tracking anyone as the sender, those points aren’t applicable. If I am, I’m going to use HTML anyway.
if you are using an email client that only supports plain-text, we’re probably already in some Matrix.org chatroom together or following each other on Mastodon and I’ll just hit you up there.
if you are using an email client that only supports plain-text, we’re probably already in some Matrix.org chatroom together or following each other on Mastodon and I’ll just hit you up there.
The plain text email train has left and will never return. Everywhere it is HTML only. People expect that. Paste a Spreadsheet part from Excel, highlight something, bold something, inline images, etc. Quoting on top ... all bad things happen in mail first.
Plain text email with hard line wrapping looks awful on most devices except terminals.
As someone who invented email DSL in org that did heavy email marketing, yes, please use plain-text, save dev time 500 hours a year. Generated image from html is also doable. When user click image link in email, it goes to that html page.
Which developer is being saved 500 hours a year?
Anyone that's responsible for implementing email layout from marketing team's mockups.
Marketing: lets try this new fancy widget floating on the left and that on the right, make it look good for Outlook v.xxx+ on android urghhh.
Marketing: lets try this new fancy widget floating on the left and that on the right, make it look good for Outlook v.xxx+ on android urghhh.
My tip for thunderbird users is to just use both.
Hold Shift while clicking buttons like "Reply", "New Mail", "Forward" etc to change from plaintext into html (or vice versa, depending on your default).
Hold Shift while clicking buttons like "Reply", "New Mail", "Forward" etc to change from plaintext into html (or vice versa, depending on your default).
Honestly if the default font for composing and reading was better I'm sure I'd like the look and feel of plaintext much more. Surely it's a setting somewhere, I just haven't gone looking for it.
In thunderbird you can do this quite easily. Edit|Settings|Fonts&Colors|Advanced. You can pick your default fonts for sans, serif etc and decide if plaintext should use a monospaced font or not.
I think most mail clients can do this, but thunderbird is what I use. On Windows, preferences may be under Tools instead. No idea on Mac.
I think most mail clients can do this, but thunderbird is what I use. On Windows, preferences may be under Tools instead. No idea on Mac.
I‘ve had problems with plain text emails being treated as spam, but send the same content as HTML and it’s allowed through. I’d send more plain text emails, but it would cause more problems.
Discussion from 3 years ago: https://news.ycombinator.com/item?id=20513987
[deleted]
No. Email clients should all just be forced to render modern HTML properly, so we can do away with all the terrible un-responsive emails.
This is why we stick with ConvertKit.
Other email providers make you jump through hoops to send an email newsletter that looks like it came from a person.
Other email providers make you jump through hoops to send an email newsletter that looks like it came from a person.
TIL about aerc. For me it's most important feature relative to mutt is having an async IMAP client! I will be trying it!
until you eradicate the likes of Outlook and Gmail from the internet, I think this is pretty much a lost cause.
Gmail works in plain text just fine. Bottom-quoting, everything.
I have it configured to plain-text by default.
If you're going to blame webmail, then blame the crappy broken webmail clients: Hotmail, Yahoo, AOL, etc.
But not Gmail. Its good plain-text handling is one of the reasons I use it.
I have it configured to plain-text by default.
If you're going to blame webmail, then blame the crappy broken webmail clients: Hotmail, Yahoo, AOL, etc.
But not Gmail. Its good plain-text handling is one of the reasons I use it.
Nah, I'm going to blame Gmail as well because a ton of problems that I still encounter have to do with what Google/Gmail has done to email as we know it.
Nice that you have it set up that way but most people don't, therefore Gmail is still part of the problem. users just accept the defaults and that's part of the problem too.
I hate gmail, and always will. I think that google/gmail has caused untold damage to the internet as we know it and I will never use Google products again.
Nice that you have it set up that way but most people don't, therefore Gmail is still part of the problem. users just accept the defaults and that's part of the problem too.
I hate gmail, and always will. I think that google/gmail has caused untold damage to the internet as we know it and I will never use Google products again.
Don't blame the tool for its users' incompetence.
Gmail does plain text email just fine, and it's a major feature for me.
Gmail does plain text email just fine, and it's a major feature for me.
"How about you use an email client from this century." --the IT guy at a place I worked
HTML in email was a deeply horrible idea with no justification beyond "Well, Microsoft wanted to make some emails prettier…"
No, it's 2022.
Plain text is preferred always; no pixel tracking
sbuk(1)
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.