There are two main types of emails on the internet: plaintext and HTML. The former is strongly preferred, but often isn’t set up by default. We’ll get you set up right.
[…]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.
I am 100% in the camp of plain text email, but sadly, very few other people – or organisations – are. Some emails become entirely unreadable when displayed as plain text, which is a pain to deal with.
I am 100% in the camp of HTML email because it allows me to send links without having to put urls in parentheses and allows me to clearly mark things like blocks of code without having to resort to using things like >>>
Also, long emails can be formatted with underlined/bolded headers and the like.
If you are one of the people who read their email in a terminal, you should buy a pixel-addressable monitor. If you are one of the people who read their email in a terminal emulator, it’s time to realise email has moved on from the era of pine so it can stay relevant in the modern era and subsequently move yourself out of pine. For the vast majority of people using a graphical application to check their email, having real formatting options is definitely worth the non-existent trade-offs.
I guess you are not seeing the real point here. I don’t give a shit about reading emails in a terminal, yet, I *still* don’t want to read some customly formatted email in shitty style.
* I don’t want people to fuck up their links so my email client thinks the mail is spam.
* I don’t want people to use WINDINGS smileys which on my systems (including Android!) show up as J J J J. It is the year 2019, UTF exists!
* I don’t want people to format fancy blocks in their emails.
* I don’t want people to embed images in their emails so that I cannot easily extract, and more importantly, remove them from the email, like I could with attachments.
The basic formatting options of plain text work very well: *bold*, _underline_, automatic links and coloring based on cite level (>/>>). Nothing there that I ever missed.
Ford Perfect,
Well just because rich text is available doesn’t mean it’s always necessary – it certainly can be abused. However I don’t think anybody ought to deny there are times it really is useful to improve both clarity and expressiveness. Obviously we use rich text formatting on blogs and websites (as the author himself has done), the motivation for using it in emails is pretty much the same.
I’m really not sure what this has to do with html. You can screw up a link with or without rich text. Copy/pasting links seems to work fine in all the clients I’ve used, YMMV.
I’d file that under abuse, but I don’t think I’ve ever received an email using windings fonts even once. So I’m not sure this one was even worth mentioning, haha.
Some of us find HTML emails provide benefits that aren’t easily replicated in plain text. If you want to set some guidelines for when it’s appropriate to use, then I might be able to get behind that, but if your opinion is that rich text emails are never desirable, then I think most people would disagree. If you are in charge, then of course you’re free to decide whatever policy you want for your organization.
I’m not really sure what you mean, I don’t have this issue with thunderbird.
The web would have never evolved to rich text if that was the case. Even the author himself uses HTML/CSS to get his points across because formatting and coloring are extremely useful for transforming a monstrous wall of text into something more pleasant and readable. Just because we have the capacity to get by with plain text doesn’t mean we must limit ourselves to it as an absolute rule. Honestly I’d have more respect for the opposing view if it were calling for moderation rather than a total prohibition, which is both regressive and futile.
Thom Holwerda.
While I understand your preference for plain text, I think it’s days are over for most organizations and quite frankly I personally use HTML features all the time in email (like coloring, underlining, images, tables, links, etc). For me, it’s not that I’ve given in either, those are features that I find genuinely useful for collaboration.
From article…
IMHO he’s living in the past and ignoring the reasons HTML email are so popular. Sure the technology and best practices could be better, but by rejecting all progress since plain text, he’s alienating most of the planet.. I think he’d be better off publishing a best practices for using rich text than rejecting it completely.
This is by far, the least convincing prose I’ve ever read. Why plain-text? “Because it’s strongly preferred.” Preferred by who? Why is it preferred? Sounds more like someone who did not give more than 5 seconds of thought to the idea they were defending. All items listed under “Why is plaintext better than HTML?” can be easily debunked. Using plain-text for email brings the following saying to mind: “If your only tool is a hammer, every problem looks like a nail.”
To address one issue that was brought up, HTML emails are not “mainly used for marketing”. Instead, it is mainly used to write professional, well thought out emails. HTML allows the writer to use, among other features of rich text: lists (both ordered and unordered), strong and emph tags, the options between starting paragraph or a simple line-break, and links. The fact that features of HTML are abused, does not make it worst than plain-text. By the way, the same arguments can be used to support a conclusion that “RTF is strongly preferred.”
I guess if you do not want to be taken seriously by employers and peers outside the “minimalism for the sake of minimalism” crowd, use plain-text. For the rest of us, HTML or RTF is going to continue to facilitate effective and efficient communication.
I’ll end with this one other relevant quote: “Everything should be made as simple as possible, but not simpler.”
Actually, I think HTML mails are better for readability. The sentence that HTML mails are mainly used for spam is false. I use them constantly in my company to bold, color, links and put images. Note that the page says:
“But if plaintext is so good, why is this page written in HTML?”
This is a reference document, not an email, you twit.”
But emails ARE documentation, so having a good format is preferred.
Also, I didn’t know until today, but RTL languages can’t be represented well if they’re not in HTML, so in fact, it’s better for accessibility also.
aarroyoc,
That’s a great point, he implicitly acknowledges the superiority of rich text by using it himself. To the extent that one were to take his arguments seriously, then each and every one of his arguments against using HTML email under “Why is plaintext better than HTML?” technically applies to webpages too. Despite all the effort he has put into the website, it does not seem like he has an answer for the question that you quoted. At the very least he would need to explain why describing something in an email does not warrant rich text but doing so on a webpage does. I’d still disagree with him in any case, but even trying to think about it from his point of view, it seems pretty arbitrary…I think he should rewrite his website as pure text 🙂
What HTML gives is most of the time convenient, and sometimes necessary.
For me, the worst part is the advice to hard-wrap your text at 72 characters with newlines. This is outrageously irritating.
Newlines should be semantic, not merely graphical formatting. The email client should be able to soft-wrap the text to whatever width is necessary or preferred, which is probably much more than 72 charts, and if it’s less, well, 72 ch hard-wrapped lines are going to look terribly messy…
Top posting is very useful in all those situations where you need to forward a conversation to someone that wasn’t previously included as a recipient.
“Some clients can’t display HTML emails at all”
Ahaha. No, seriously, is this a valid reason to promote text-only emails? It’s like saying that photographs should be shot in grayscale, because there are printers that use only black ink.
By “some clients” he means pine or other terminal-emulator garbage. Some people just don’t want to move on.
Another problem with plain-text emails is that the fonts will be whatever the default font will be on the target computer (best case scenario), or worst case scenario some intermediate system will format it as beautiful (not) monospace text.
BTW we had a guy at work who insisted python code should wrap at 80 columns, because the PEP8 standard says so, and because someone might want to view it with vi (“not vim” as he said).
Of course, python applies semantic meaning to newlines, so that code is now a pain to read.
What does it take to convince people nobody actually has an 80-column terminal anymore?
emarsk,
I agree. My vote is that emails SHOULD NEVER be hard wrapped to fixed widths such as 72 or 80. For starters, 80 characters is an arbitrary limit that has no relevancy today even for many console users. In graphical clients most fonts in use today are not monospace fonts and it makes very little sense to have a fixed number of characters per line. Rather than wrapping text at the source, where the sender has no idea how the text is to be rendered, the sender should leave the line alone and instead the the receiving client should auto-wrap to it’s own width whatever that happens to be. If there’s a client that fails to do this (even if it’s truly limited to 80 character text mode), then that client is buggy and should be fixed. It shouldn’t be a burden on the rest of the world to wrap text at 80 columns at the source. We’re long past the days of 80 character displays and even in that case there’s just no benefit to wrapping text at the source.
I use Alpine and plaintext, largely agree with the article and also have an irrational dislike of HTML email.
But even I agree with you here: the hard line-wraps are enough of a shitter to stop me from recommending other, normal people use plain-text emails. Clearly the clients should be soft-wrapping rather than A) automatically hard-wrapping (like Alpine) or B) not doing anything at all (Gmail?).
That article presumes that the overwhelming use of emails is either for letters or a instant messaging. Actually people do sometime need to lay out more complex stuff, like documentation, instruction &c. Unless you want to train every email user in the world to use mark-down really, really well rich-text email is inevitable.
Also, taking soft-wrapping off on a tangent: Its amazing how bad the readability design is for almost all GUI clients and webmail clients. None of them have a HTML-email soft-wrap column-width based around readability guidelines: 60–80 characters per line. On a 23″ monitor they will give you 120–160 characters per line. Talk about bleeding eyes.
Can’t these people just make Alpine HTML compliant? It doesn’t have to render anything, just skip over the HTML tags. HTML says you should skip any tag you can’t render and if the content of the tag is textual just render it as plain text.
I hate plain text as a communication method, so I have an irrational fondness for HTML. If we didn’t have to use *stuff* _like_ -this- and this >> and urls in parenthesis, communication would be much more natural.
Alpine is already HTML compliant. It shows HTML emails with bold text, padding, headings and all that, and, as you say say, it ignores the tags it doesn’t understand. (Press ‘v’ and you switch between HTML view and plain-text view, FYI.)
Unfortunately I think you have a view of Pine/Alpine, expressed in this comment thread in particular, which isn’t based off either trying it or understanding it.
I think your dislike may be based to a large extent off a misunderstanding.
I was talking about the limitations of writing plain text email, especially relating to line-wrapping, not the problem with TUI clients. Alpine actually does an excellent job of looking at rich-text emails.
“Can’t these people just make Alpine HTML compliant?”
Who are ‘these people’?
Markdown is the answer. It has nearly all the formatting one needs (except for color), and is still readable using plaintext clients. MUAs should support text/markdown MIME type.