Live data from Hacker News

Use plaintext email

useplaintext.email

251–260 of 345 posts

Re: Use plaintext email

#251
post #158
post #98

Earlier quoted context omitted.

hard wrap at 72 characters seems pretty conservative

The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example: >>>>>>>>This line was 72 characters long, but is now 80 characters long instead.

    Still looks pretty
    bad on anything
    less
    than 72 characters
    because there's
    random
    newlines in the 
    middle of 
    paragraphs. 
    
    Content should be
    separated from
    presentation.

    Additionally 72
    characters implies
    monospace 
    fonts which have
    been shown to be 
    less
    readable.

Re: Use plaintext email

#252

Earlier quoted context omitted.

For the vast majority of people html formatting is better and more efficient for their communication needs. Bold and highlighted text, section headers, tables and inline images are all very very standard and useful things to have in emails. These are not niche use cases.

I have never seen an email with a table in it, HTML or not. Inline images are not useful, just attach them. Leave your giant signature with your company logo at the door. What's left is section headers and bold text. Use asterisks for emphasis and # for section headers and you can communicate quite effectively. We seem to manage pretty well here on Hacker News without most of these features, wouldn't you say?

It takes a special kind of narcissism to say “I don’t use tables, therefore no one could possible have any use for them.”

Attached images are worse for readability. Instead of writing “blabla refer to attached image 3 blabla now look at image 4”, it’s far more convenient to just insert inline images at the locations where they are relevant.

Instead of using stupid hacky workarounds for italics and headers why not use ACTUAL italics and headers?

Your entire argument revolves around the fact that you have a narrow minded, arbritrary, and old fashioned view of what the platonic ideal of an email is supposed to be. You can keep being the old man who yells and clouds if you want, no one cares if you get personally offended by the concept of section headers in emails, we’re going to keep doing it.

Re: Use plaintext email

#253
post #7

Earlier quoted context omitted.

Keep reading the article: 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. and more at https://useplaintext.email/#why-plaintext

The idea that marketing emails = "you don't want them" is fairly popular in some crowds, but it's contradicted by the tremendous business success of using marketing emails. The reality is that most people want and use marketing emails. For example, I'm signed up for marketing emails from several airlines and these routinely save me money when booking vacations. Cheap airline tickets are a limited resource, so real-ti…

but it's contradicted by the tremendous business success of using marketing emails

I know advertising is effective, it IS manipulating me. That's WHY I don't want it. "I don't want them" is not contradicted by the success of marketing, it's reinforced by the success of marketing.

Re: Use plaintext email

#254

I’d love someone to convince me I’m wrong - but I think we’ve lost this fight. Years of use of plaintext hostile clients by people who read our emails means bottom posting or inline replies are seen as extremely strange, and impossible when you have one of those “seven email deep” threads forwarded to you. (I know, I know, “snip it down”, but sometimes I just don’t have those minutes in my day ;)) Wrapping as well ha…

There's no losing as long as you're being the change you want to see. I will always send plaintext emails and I have the technical skill to dig into the raw email and decode the encoded HTML data manually or rip out the relevant authorization URL/strings.

You’ve just made the problem an externality. While you have the skill and desire to do that - and to be clear, as a mu user I do the same dance when I need - inbound messages are rarely the problem for me.

What is a problem is outbound messages. When I try to do (what I think is) the right thing and trim the message and reply inline or bottom post, confusion abounds. I’ve had messages missed because the recipients told me they thought I accidentally sent an empty reply and didn’t scroll past the “on July 24th, superkuh wrote:”

Whose fault is that? Is it the 20 people on the distribution list who learned email protocol from years of Outlook and not “the right places?” I don’t feel comfortable pushing that blame onto them.

Re: Use plaintext email

#255
post #113

Earlier quoted context omitted.

That stuff is actually not that hard, mozilla's engine has compile flags for that stuff and the patches you have to make are minimal. There are a few methods for runtime restrictions too, they're quite extensive in their capabilities and sufficient for sandboxing a mail.

Mozilla's engine is a giant multi-million lines-of-code ball of C++ and Rust and JavaScript weighing in at nearly 200 MiB - not including dependencies. And what if I don't want to support the browser monoculture? Implementing a new one is a daunting task (nigh impossible), but rendering plaintext is easy peasy. Mutt is 1 megabyte.

HTML email in practice doesn't need much more than what w3m supports, in some places less - no need for w3m's frame, cookie, or FTP support. w3m is smaller than mutt.

Limiting HTML mail to an agreed subset could actually be a winnable fight compared to more impractical suggestions.

Re: Use plaintext email

#256
"How about you get a mail client from this century?"

--Actual response I got when I complained to an IT admin at a former company that Exchange had started eating all plaintext versions of emails

Re: Use plaintext email

#257
Plaintext email was doomed from the moment it got named "email" rather than "etelegram". Regular mail can include graphics, different fonts, color, bold, etc., so it is natural to expect email to handle that too.

Early email systems could not, but because they ran on systems that could only display simple text, the natural assumption is that they were plain because of technological limitations.

Once GUI systems became the norm, removing that limitation, it was inevitable that email would follow.

This is not to say that HTML email is good. It was inevitable that email would support rich text, inline attachments, and stuff like that that, but HTML did not have to be the way that was done.

Re: Use plaintext email

#258
post #191

Earlier quoted context omitted.

>Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features. Can we? Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table. Quoting from the article is very difficult, as laws and guidan…

> Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table. It can be done in plain text, but I don't commonly see it. For example: Column 1 Column 2 first second third fourth > Quoting from the article is very difficult, as laws and guidance often use formatting d…

The OP's point is that it might be better if HN allowed slightly more formatting than it does. Personally, while I wouldn't want full-bore HTML, I'd like to see a more substantial subset of Markdown[1] supported. Your own examples of tables, lists, and block quotes would look a lot better if they were, you know, actual tables, lists, and block quotes.

[1]: Markdown isn't perfect, but it's pretty well-known, and by design mimics a lot of conventions that came from plain text email to start with.

Re: Use plaintext email

#259

Earlier quoted context omitted.

I have never seen an email with a table in it, HTML or not. Inline images are not useful, just attach them. Leave your giant signature with your company logo at the door. What's left is section headers and bold text. Use asterisks for emphasis and # for section headers and you can communicate quite effectively. We seem to manage pretty well here on Hacker News without most of these features, wouldn't you say?

It takes a special kind of narcissism to say “I don’t use tables, therefore no one could possible have any use for them.” Attached images are worse for readability. Instead of writing “blabla refer to attached image 3 blabla now look at image 4”, it’s far more convenient to just insert inline images at the locations where they are relevant. Instead of using stupid hacky workarounds for italics and headers why not use…

Couldn't help but notice that your ad hominem attack was conducted entirely in plain text.

Re: Use plaintext email

#260
The list of recommended mail clients had nothing for mobile. Is it because good ones don't exist?

I'm a happy GMail (android+webmail) user because the usability is good enough and I don't need to install and configure stuff.

If I wanted to send plaintext email from my Android phone, is there a reasonably easy and usable way to do it?

Post reply on HN