The most contagious/problematic issue is (3) and inlining - as I said, it's possible to attach anything but the location is lost. Probably something simple like anchor (again, markdown linking comes to mind) to indicate placement would be just fine...
(I loath html mails with passion…)
I think this comment displays the problems with plain text. I really couldn't have provided a better example.
As regards the counterpoints:
1. All links are clickable
Yes, and that's a bug. "http://www.example.com" should not be a clickable line. More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software.
2. It's not obvious how this should be done, and how it should reflow. You yourself failed to manage this in your reply, which I consider a good argument for why plain text is a poor UI.
3. Who cares whether you need it or not. The reality is that the clear majority of people use it!
4. Once again, if we're talking about a specific format that gets rendered into something readable, then it's not plain text anymore.
I'm arguing against the GPs assertion that plain text is the best format, not that markdown is insufficient.
Arguably it is. It was sent as plain text and received as plain text. The fact that the recipient's software goes through and interprets that plain text and does something when it detects an URL in it doesn't change that. If the recipient were to use some other software that doesn't do that, they'd see... Plain text. Because that's what it is.
Exactly like .... the subset of HTML we see in emails?
I have not yet gotten an HTML email that, when displayed in plain-text, was unreadable. Neither, I suspect, have you.
I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything.
> not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place)
For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Sadly many people on HN do exactly this, as seen in comments like
"I don't use a phone and don't have a phone number, so I can't pass the anti-spam check of xx website. It is their fault"
"Why do we need a UI for this? Command line is much better than this"
"Why do we need to do this? I have been installing applications by compiling from source since 199x and it has worked perfectly fine for me."
PS. I assume all your github readme.md are all in full-blown HTML sprinkled with tracking links? :P
That's the thing - I do get lots of them. In the age of html+plain and abuse of tracking (because it's so easy to hide with html), plain text version is just littered with this nonsense...
For example I just got notification from allegro.pl (shopping platform) and all links have that:
`?utm_source=notification&utm_medium=cartWithPayment&utm_campaign=cef…35-c856-…-…-687c…cdd6&tr_n=buyer-cart&tr_id=f09…d40-…-…-…-05b0…7126-…__f09d2e80-…-…-…-05b0ee617126-…&tr_d=allegro.pl&tr_c=purchase-details&tr_s=LM…sCz>`
As for attachments - obvious exaggeration to dismiss actual issue: bravo…
> You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.
Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
> As for attachments - obvious exaggeration to dismiss actual issue: bravo…
No, the issue is that you can't tell everyone to "just upload the picture somewhere and put the link in the middle", that's unreasonable. That is the issue. HTML solves an issue.
> Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it
Average users want formatting. Plain text doesn't provide it. HTML for emails sucks, but plain text isn't a solution to that.
If only. Everyone I know who isn't an IT professional -- and many who are, too! -- sends links like https://www.example.com/something/somepage/?tracker=ASfas142......
If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user.
[1] For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too.
The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.
Yes it is.
> It's a format
Yes, plain text is a format. The best format.
> in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.
Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML.
> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
> Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
I can't tell if you're being purposely contrarian or simply don't understand users.
The problem: Things that shouldn't be links get turned into links.
Your response: $SOME_OTHER_PROBLEM
I mean, really? You can't tell the difference between someone making a typo when intending to write a link and someone making a typo that results in a link?
Or, if you want, the problem is that the recipient's client software HTMLifies text. Stupid client software (and possibly stupid recipient, for using the stupid software). Still has nothing to do with HTML vs text per se. Yes, that is literally $SOME_OTHER_PROBLEM. I mean, really? You can't tell the difference between various formats and problems caused by something else entirely?
(I get the feeling your supercilious "I mean, really?" was intended to slyly convey that I was the one being stupid here. IMO that backfired rather convincingly.)
Your first statement might be true (it's debatable). Your second is definitely false.
Lets assume that HTML really was the worst thing that ever happened to email. Plain text content for email is still not the best content.
People want to:
1. Click on a link in the email, not fumble with copy and paste on their phone.
2. See decently formatted paragraphs and content with bold, italics and different font sizes for headings and paragraphs, not a wall of text.
3. See images in the email itself, not have to once again fumble around with copy and paste.
4. Correctly formatted bullet points, including sub-lists.
For all of the above, some sort of format is required. If we exclude HTML as a possibility, you're still going to have to need a format of some type, because the wall-o-text format is not a good UI.