[CM30]

It's a good start, and something that's very useful for people coding HTML emails.

That said, we still need to get this sort of thing in Microsoft Outlook, and both that and Gmail really need to support CSS to something of a normal standard, like with say Apple Mail or what not. There's no real reason email standards should be different to browser ones, except with the former not having Javascript included.

[haimez]

Good luck stopping a browser from implementing a "fun" javascript API just because it opens a security or usability hole in email.

[jcranmer]

No email client that I'm aware of supports JS in email. (Thunderbird used to have a hidden option for turning it on, but even that was removed when we doubted the ability to enforce sandboxing at all). All email clients sanitize the HTML in email to some extent anyways.

[networth]

Put it in a safe iframe, whats the catch?

[haimez]

Everything. iframes can't fuck with you code, but they are 1. displayed in your page (is this a good idea, does this iframe agree with how your page will display it). 2. Is leaking information to this iframe (and consequently, that iframe's server that this email had been opened) a good idea (no. 100% it's not.). 3. Can someone else contrive another vector of page control or information leak that suits their motives and hasn't been considered a priori by you (also yes, 100%. Never underestimate the motivation or creativity of others).

Never, ever, EVER embed an iframe thinking it will make your life better.

[networth]

Are most of these protected by sandboxed iframes? What kind if leak are you talking about? Referer leak? That is easy to fix, but what else?

I dont think email sender cares about how iframe is rendered. They currently render in a rectangle, and they will keep render in a rectangle.

[fungi]

You can have a lot of fun placing elements over the web mail client buttons.