Honest question: wouldn't it be simpler for text-only email readers to have plugins that runs HTML-only emails through a command that converts the HTML to text?
The problem is when the email explicitly includes a plain text part which is an empty string (or a generic one-sentence placeholder), and a separate html part. In these cases, the email client is right in defaulting to the plain text version.
I don't think so. If you print the HTML, it's often full of " ", images and links unrelated to the actual content. It's hard to extract the meaningful part of that pile of stuff in a trustworthy way (and you wouldn't want to lose information).
Also many of those emails are autogenerated. So the template has to be done once, and that's it. And it should be trivial for whoever composes the HTML email to copy-paste the important part into a text-only version. Maybe it would actually help them think about what the important part actually is.
Decoding and other entities should be part of converting the HTML to text. This is absolutely basic.
> So the template has to be done once, and that's it.
Except the world is not static and then when the HTML template gets updated they'll forget the text template and now you are missing vital information. Perhaps even legally required information like unsubscribe links.
Supporting text email only makes sense if that will actually be tested. Otherwise you are better of just rendering the HTML to text locally. That's going to lose you less information than a forgotten text mail template.
I'm not saying it's impossible. I'm just saying that they make my email experience worse by only sending HTML, and most (all?) of the time, it's absolutely unnecessary.
