> 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.
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.