[Rudism]

> If an email has a rich, HTML view; it should be required to come with a text-only, non-HTML copy of the body as well; for accessibility, compatibility, and privacy reasons.

I can't imagine this working. The plain text section would probably something like "Upgrade your email client to view this message" 90% of the time and be completely pointless.

Maybe it's an unpopular opinion but if I were rebooting email I'd forego HTML entirely and either say it's strictly plain-text, or use some Markdown-like formatting spec that looks fine even when viewed as plain text (email clients could provide WYSIWYG editors for less technically-inclined email authors). The evils of HTML in email (phishing, impersonating companies, and other scams) far outweigh the benefits (none, as far as I'm concerned).

[swiftcoder]

And exactly zero of the people who send marketing emails are going to adopt your plain text email replacement. In the year 2024 we ought to be able to format text and add images to our communications.

For the folks who really want to RETVRN to the days of plain text, command line mail clients are still a thing.

[withinboredom]

My old marketing department would beg to differ. Plain text is easy, graphics and layout is hard. Further, all our emails were written in plain text first, then styled once we were 100% on the copy (so they could be sent off for translations in 20-odd languages).

[account42]

> And exactly zero of the people who send marketing emails are going to adopt your plain text email replacement.

Great!

[chrisjj]

> I'd forego HTML entirely and either say it's strictly plain-text

Inferior to typical print media text richness would rightly get rejected by most users.

> or use some Markdown-like formatting spec that looks fine even when viewed as plain text

No rich format can "look fine" when reduced to plain text. Reason being that the reduction loses information that the sender relies upon the receiver seeing.

> The evils of HTML in email (phishing, impersonating companies,

Neither of those evils are specific to HTML.

[Forge36]

I've started reviewing some mail as plain text first. I've noticed some are exactly this kind of junk. The hard part of making a "new email" is that it needs to substantially better than current options.

Outlook still supports RTF. (I have no idea what clients support that) Any new format could also be included as a new content type.

For all the evils, I can't see any replacement markup being a significant improvement: What is the sender trying to communicate? Why is it beyond plain text? How do attachments not fill that gap?

I think the answer is: any client could choose to behave differently on the existing ecosystem. They currently choose not to. While an individual may think it's complex, the solutions aren't truly reducing complexity.