> What I would really like is to end up in a situation where email clients all support text/markdown. It really hits the sweet spot between plain text and HTML. It has enough structure to show a nice outline, and the triple back-tick syntax is great for marking bits of text as code.
Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.
> [...] and free from the abuse of HTML email.
Are you sure? The advantage of text/plain in mail is that I see every link as it is and no resources are loaded from external sources.
With markdown support in mail clients, we might be back at early HTML support. Link destinations would be unknowable again.
> Alas. More and more companies are giving up on plain text email (even though this is required by the standard),
If it's not plain text, it has to declare a mime type (how would the mail client know how to render it?) but I don't think plain text section is mandatory.
> and simply send you a hyperlink to click if you have plain text as your viewing preference for email.
Go tell them, and you can quote me on that, that they are stupid. If my mail client doesn't render text/html and prefers the text/plain sections that is because it is configured that way.
I know of no mail client that isn't able to handle HTML.
> Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.
Is this a bad thing?
> Are you sure? The advantage of text/plain in mail is that I see every link as it is and no resources are loaded from external sources.
> With markdown support in mail clients, we might be back at early HTML support. Link destinations would be unknowable again.
Not seeing how link destinations become unknowable. With no scripting there's no way for a site to hide the destination, it is what it is. Your viewer can choose to display it however it wants. Status bar like a browser, tooltip, whatever.
> If it's not plain text, it has to declare a mime type (how would the mail client know how to render it?) but I don't think plain text section is mandatory.
It is though. That's a major advantage of Markdown, by adopting those well-established mail/usenet conventions where practical and attempting to follow that sort of principle with less defined formatting there's not really anything lost if you treat it as plain text. The other way around is almost as safe, with very little chance of a a plain text message treated as Markdown being misinterpreted in a way which significantly impacts its meaning.
> I know of no mail client that isn't able to handle HTML.
Any text-mode mail client? I mean sure there are some that can interpret basic HTML formatting and translate that to control characters for a sufficiently capable terminal, but modern HTML mail tends to go far beyond that. Basically what formatting a text-mode client can actually handle also happens to be the same formatting that Markdown supports. No images, no fonts, no colors, just paragraphs, links, quotes, and some basic emphasis formatting.
>> Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.
> Is this a bad thing?
Not a bad thing but in this case it seems a little bit pointless as we wouldn't have gained much.
It happens a lot that something that is popular now has been there a while ago so you have some old farts saying "but we already had that 20 years ago!" although often there are some crucial changes to how it looked then so that it now has a completely different impact.
For example, we are about to get WebAssembly in the browers, essentially a bytecode VM. We had that 20 years ago with Java, although the integration of Java and the browser was not tight enough. Or VR which 20 years ago was quite hyped and then somehow just died down and for all I know the difference to today is only that the graphics was crappier back then.
Markdown in the mail client doesn't give you much over what we had 20 years ago. If I enable format-flowed and use a variable-width font, it probably looks quite similar to the rendered Markdown.
Oh, one thing I forgot about unstyled HTML pages. Mobile browsers suck a rendering that.
>> I know of no mail client that isn't able to handle HTML.
> Any text-mode mail client? I mean sure there are some that can interpret basic HTML formatting and translate that to control characters for a sufficiently capable terminal, but modern HTML mail tends to go far beyond that. Basically what formatting a text-mode client can actually handle also happens to be the same formatting that Markdown supports. No images, no fonts, no colors, just paragraphs, links, quotes, and some basic emphasis formatting.
Any text-mode mail client will have ways of rendering HTML with the help of external programs. That's not surprising, as they already needed that for things like images or PDFs. Some even let you fire up a browser to read them, some have some basic HTML parsing capabilities but I think most just do let some program convert the HTML to text to display inline as if it were a text/plain section.
As you can't rely on scripting being enabled (are there actually any mail client that still have HTML scripting?) the HTML needs to have all the text you want the receiver to read, so converting it to text usually works fine. I can't remember reading any legit HTML mail in the last years where this wasn't the case.
I said "handle". Especially Unix programs almost always have a way of going beyond a programs limitations.
Elm and pine support mailcap files. IIRC (n)mh does as well via mimeview (or is that only the GNU version?). But a program where scripting is a part of its core design, there will certainly be ways of calling an external program for converting HTML to be viewed.
Mail and mailx, do they even support mime types? AFAIK they don't but then you just need to set up PAGER with an intelligent enough program I guess.
Now if you said telnet or netcat, I would truly have been at a loss.
Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.
> [...] and free from the abuse of HTML email.
Are you sure? The advantage of text/plain in mail is that I see every link as it is and no resources are loaded from external sources.
With markdown support in mail clients, we might be back at early HTML support. Link destinations would be unknowable again.
> Alas. More and more companies are giving up on plain text email (even though this is required by the standard),
If it's not plain text, it has to declare a mime type (how would the mail client know how to render it?) but I don't think plain text section is mandatory.
> and simply send you a hyperlink to click if you have plain text as your viewing preference for email.
Go tell them, and you can quote me on that, that they are stupid. If my mail client doesn't render text/html and prefers the text/plain sections that is because it is configured that way.
I know of no mail client that isn't able to handle HTML.