How is Gmail not supporting 'box-shadow' or ignoring 'display: none;' but allowing 'display: none !important;' a security feature? Not supporting classes? Why does AOL messes with inline URLs (so that they stop working)?

This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.

And then there's Outlook. My quality of life is so much better since I left the email marketing industry.

This is sadly misinformed. Having had to create business emails in the past, it's frankly a nightmare, and I can't agree with anyone who doesn't see that.

Having a universally implemented, and uniformly implemented, limited subset of CSS would actually improve the situation for you.

Although I agree with you, I generally should trust my email provider to not mess with my email, however I choose to receive it.

Sure, html email is annoying, but let there be a flag or option for the user to decide to display it or not.

There are some good reasons why email clients do modify HTML: security is one, but they also have to make sure malformed HTML can't break the rest of the page. There are also reasons why they don't publish clear documentation on what they do to it, but this mostly means huge headaches for anyone who tries to create HTML email.

> they also have to make sure malformed HTML can't break the rest of the page

What do you mean? That's the point of iframe, so the email content cannot break email. We have object urls[1], and it's really not super hard to put emails into a different url to simply iframe src="" it.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Blob

My first thought it that you may be looking at what is feasible today vs what was feasible for email clients (web or client) since they've been supporting HTML email. Email has been around a long time, and thinking of email as being a vector for security concerns has been a topic for even longer than consideration of browsers as a security concern because while you can "be smart" about where you browse, you can't "be smart" about what email you receive. Email that positions elements over portions of the email client or screen scrapes your email is a big deal, obviously.

Also, I am not saying that this was the only way to mitigate this risk (Apple Mail seems to pretty much use an iframe in their client, whereas other email clients still munge the HTML (Outlook, Eudora, Lotus, etc). But it is the way that many did choose, and I can understand why whether or not I agree with how they did it.

iframes have a number of real world usability problems. One example is that iOS ignores any sizing of the iframe, automatically growing it to fit its content, which could easily mangle the rest of your layout.

> they also have to make sure malformed HTML can't break the rest of the page

    <iframe src="/actual/email"></iframe>

Please, add a sandbox attribute on your iframes. I have outlined the reason for this below.

Changes what you can then do with the email. If you want to hide quoted or let users select specific text for forwards, you're SOL.

As long as they're on the same domain, you should be able to reach into the child iframe. Used to be a common technique for handling file upload progress before AJAX support for uploading became commonplace.

The child can reach up to the parent via JS, too, but you'd want to sanitize any JS in an email anyways.

Anyone who doesn't do this is asking for trouble

"Limited" is OK. Inconsistent across mail apps is bad.

I could say the same thing about the web itself.

Leaving Javascript out of email is just good sense. Leaving full support for HTML+CSS is not.