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?
I don’t see the need to write why I’m saying no. There are over 1000 words in an article that says nothing. This is someone that is pissed off because they basically want to use email like it was 1979.
I don't necessarily agree with the article (and I don't see it ever being possible to get the world to move back to plaintext email), but the article isn't saying nothing. There are legitimate reasons to want plaintext email. I wouldn't dismiss it in the way you've done. We (HN community) can and should have better discussions than this.
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.
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.
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.
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 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_.
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.
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.
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.
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.
"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 abbrevia...
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.
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>.
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.
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.
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?
> 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.
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 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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
> ...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!
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.
> 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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.).
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.
> [...] 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.
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!
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.
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 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.
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.
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.
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.
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 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.
205 comments
[ 3.0 ms ] story [ 249 ms ] threadhttps://news.ycombinator.com/item?id=20513987
proceeds to write a nearly 3,000 word document with rich formatting an inline images...
Why should you bother using markup on a webpage? How do those reasons never apply to sending an email?
[1]: https://freron.com/
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.
For €62, i wonder how often a new version arrives / i'll have to buy/upgrade again...
Which also works in Facebook Messenger and in WhatsApp, which very few people seem to know.
OK, here, I made you a screenshot.
https://imgur.com/a/frml6cs
I'd be perfectly happy with Markdown or likely RFC 1896 as someone else mentioned.
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.
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 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_.
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.
> "Plaintext Certified" graphic by Jens
[1]: https://git.sr.ht/~sircmpwn/useplaintext.email
[2]: https://sourcehut.org
https://www.rfc-editor.org/rfc/rfc1896
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 abbrevia...
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.
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>.
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.
To make maters worse, there's now AMP for email, https://amp.dev/about/email/
Other email providers make you jump through hoops to send an email newsletter that looks like it came from a person.
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.
This is a client-side issue, IMO. If someone doesn't like HTML, simply don't enable parsing of it and view the source.
2. The bloat/ugliness argument could also be applied to websites, but no one is out there advocating for plain text websites.
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?
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.
The gemini folks (gemini.circumlunar.space/) basically are, but I think it's a similarly niche / reactionary take.
> "But if plaintext is so good, why is this page written in HTML?"
> This is a reference document, not an email, you twit.
https://www.rfc-editor.org/rfc/rfc5322.txt
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.
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.
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.
[0] https://www.jwz.org/blog/2017/09/html-email-was-that-your-fa...
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!
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.
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.
I believe that "Insert file" should insert a picture in the middle of the plain text, unlike "Attach file".
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.)
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.
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).
Stops reading.
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")?
Whaaaaat? How about a more honest version...
> HTML emails are mainly used BY LITERALLY EVERYONE
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.
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 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.