Live data from Hacker News

Use plaintext email

useplaintext.email

301–310 of 345 posts

Re: Use plaintext email

#301

Earlier quoted context omitted.

The page footer might interest you. It directly answers your question. Quoting "But if plaintext is so good, why is this page written in HTML?" This is a reference document, not an email, you twit.

That's pretty much a non-sequitur. HTML is better in email as well as "reference documents" according to the opinions of many. You don't like thing. Okay.

RFC 822 is plaintext. That's a reference document. Don't see why HTML would be an argument for a reference document. In fact, tex is a good format for reference documents, it diff's well and can produce .ps/.pdf outputs among others.

Re: Use plaintext email

#302

Earlier quoted context omitted.

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 to…

> 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:"

A common way to handle this when writing to people who aren't likely to expect an inline response is to put "Responses inline below:" at the very beginning, and then respond inline as usual.

Re: Use plaintext email

#303

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?

I often use inline images in emails, for the same reason I put images inline in other writing. I recently wrote an email summarizing some debugging I had done so someone else could pick it up. It looked like:

    text describing steps

      image of graph
      link to graph source

    more text

      another graph
      link to graph source

    etc
We're all using email clients that display messages like this well, and it makes communicating complex ideas much faster.

I'd give up HTML email if I could still have format=flowed and inline images, but that's not what's on offer.

Re: Use plaintext email

#304
post #174

Earlier quoted context omitted.

Don't even need that account: at start, this works in chrome: https://www.paypal.com@google.com

In Firefox it tells me: You are about to log in to the site “google.com” with the username “www%2Epaypal%2Ecom”, but the website does not require authentication. This may be an attempt to trick you. Is “google.com” the site you want to visit?

From the error message it sounds like if this was an attacker controlled site configured to require authentication it wouldn't trigger? If so it's not that useful a defense since whether to require auth is entirely under the attacker's control.

Re: Use plaintext email

#305
post #65

Earlier quoted context omitted.

Screen readers should be able to deal with HTML-only mails for the most part, otherwise you should send the sender of that mail a reminder about those laws.

Are you actually a user of accessibility? To me, it doesn't feel like you are. If I am right, please refrain from patronizing people who actually do. In my book, you have no idea how horrible the situation has become over the last 5 to 10 years. Accessibility used to be a thing, yes. These days, it is mostly a happy accident.

I've never talked to anyone who actually used accessibility tools. I'm aware of the W3C standards. Are there any other resources that developers can use to produce stuff that works well with real-world accessibility software?

Re: Use plaintext email

#306
post #297
post #251

Earlier quoted context omitted.

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.

> Content should be separated from presentation. Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case. There is an RFC[1] t…

> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown

Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or

code
is handled properly.

Re: Use plaintext email

#307
post #233

I greatly prefer top posting because it emphasizes what I'm looking for in a email reply which is new information. Moreover, modern email clients automatically hide the quoted text so only the reply, with the new information, is visible but context is available if necessary. For example: --- Let's meet at 8 pm. (Show more from person A). --- Typically, the context will be clear from reading the reply and the sender.…

That's only relevant because you're including your whole thread (or part of it, if there's forks) in your email. As far as I know, there's no real reason for people to do this anymore. Email clients should be able to handle email threads themselves, and then the recipient can decide how they want to sort it.

If you're only replying to things that are specifically relevant to the section (what quoting was traditionally used for), then bottom-posting doesn't make sense.

Re: Use plaintext email

#308

Earlier quoted context omitted.

> People use [...] Not in my experience. They hit reply, type something at the top with whatever the defaults are, and hit send. > Is it really that hard to wrap your head around the fact that formatting is useful for communication? I have all of Edward Tufte's books, as well Bringhurst's Typographic Style , and Chicago : I am aware of the usefulness of typography. I simply have not seen it in my day-to-day e-mails a…

I see useful text formatting every day in the emails I send and receive. A reasonable person would accept that other people’s use cases and preferences are valid instead of writing haughty diatribes about what the platonic ideal of email should look like.

I accept that other people's use cases and preferences differ.

But given the carnage that HTML e-mail being the normal has caused in phishing and other privacy invading manners, I question whether the benefits of those use cases and preferences out-weight the detriments of the practice. Just ask John Podesta:

> SecureWorks concluded Fancy Bear had sent Podesta an email on March 19, 2016, that had the appearance of a Google security alert, but actually contained a misleading link—a strategy known as spear-phishing. (This tactic has also been used by hackers to break into the accounts of other notable persons, such as Colin Powell). The link[10]—which used the URL shortening service Bitly—brought Podesta to a fake log-in page where he entered his Gmail credentials.[1][9][11][12] The email was initially sent to the IT department as it was suspected of being a fake but was described as "legitimate" in an e-mail sent by a department employee, who later said he meant to write "illegitimate".[13][14][15]

* https://en.wikipedia.org/wiki/Podesta_emails

Or countless others who have been phished.

Re: Use plaintext email

#309

Why just only such black and white dilemma? It could be a different format altogether - something third as the golden mean. Alternatives: Markdown (we need specification for that) or HTML v2.0 or something else. Requirements to such format: - it shall provide only one way of text -> rendering and rendering -> text so WYSIWYG can be implemented in non-controversial manner. If HTML then HTML v. 2.0 as the last version…

Agree. Hyperlinks and the subset used by term emulators today. For example bold and tables can be rendered on even terminal emulators today. Another issue is probably captioning.

Re: Use plaintext email

#310

Earlier quoted context omitted.

Communicating just fine is not the same as communicating at optimum. In the analog world, you could just hand over a white, plaintext birthday card. Or you could give one with a motive, color, some doodles and maybe a memorable photograph attached. Which one is more memorable? "It's used by marketing." is not an arguments against it. We have sophisticated spam filters. Update your rules then.

iiiiiiiiiiiiiiiiiii |||||||H|A|P|P|Y||||||| __|_____________________|__ |\/\/\/\/\/\/\/\/\\/\/\/\/\/| |||||||B|I|R|T|H|D|A|Y||||||| |,,,,,,,,,,,,,,,,,,,,,,,,,,,| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@

That would be a wide cake for older people :P
Post reply on HN