Some HTML in email is fine, I would say the subset that can be expressed by markdown. Making text bold, italic etc should be possible. The real problem I have is how limited email HTML/CSS and email clients are compared to the web, so that every "rich" email will use table layouts that render terribly on mobile.

But still better than anything else that could reasonably be achieved.

Tables are pretty much the only cross-platform/client way to format email.

> Email should be plain text.

That ship sailed the moment it got named email, leading people to think of it as an electronic form of mail, and so to expect that eventually it could be used for any documents you would send by mail.

With mail, I can send anything I can print or handwrite on paper, which includes text in multiple fonts, graphics, charts, tables, in a variety of colors. I can also include anything that fits in the envelope, so I can include files on floppy or disc or memory card or a thin thumb drive.

Sure, earlier email systems could not handle anything more than plain text, but because it was called email many people assumed that was just because common computers and displays didn't have the capability to handle more.

Once the GUI became prevalent for home and office computers, rich email was inevitable.

In retrospect, if the people who designed the earlier email systems had wanted the restriction to plain text to be a design goal, rather than just a consequence of the technology of the day, they should have named it etelegram to make it clear.

There's been rich-text email since (at least) 1980 and by the mid- to late-1980s there were many competing efforts: CMU's AMS, BBN's Diamond/Slate, NeXT's NeXTMail, and probably several others.

I'd go so far as to argue that the parent's reaction -- "email should be plain-text" -- is exactly why the horrors of HTML are what we have today. No one adopted any of the better alternatives out there and then Netscape -- a web browser, after all -- hacked in HTML mail, and "worse is better" won the day yet again.

Technically email is plaintext, though for the definition you aspire towards, it was in the early days. But then various RFC's added this and that and now email processing/sanitisation is scary.

But then email is one large unsanitized input that has so many rules to be applied, what could go wrong.

That's why email attachments alone are an utter MIME-field when it comes to security.

Pure gold pun right here:

> That's why email attachments alone are an utter MIME-field when it comes to security.

And yes, remember the 35C3 talk on e2e email security.

https://www.youtube.com/watch?v=kKjtZy87iI0

> https://www.youtube.com/watch?v=kKjtZy87iI0

Not seen that, watching now (about half way thru) and nice to retouch upon a feild I've not working in for many years and seeing how not much has changed. Equally a little depressing, to see the same types of problems 10 years on.