3 ms·

Seriously. Would be great if somebody could just declare a new mime-type such as "text/html5" that could be used to activate modern html rendering in email clie

Seriously. Would be great if somebody could just declare a new mime-type such as "text/html5" that could be used to activate modern html rendering in email clients and would be shipped alongside the existing "text/html" and "text/plain" components. Eventually when enough email clients support this, we could stop generating the legacy html emails and only include text/html5 and text/plain mime types in emails.

bastawhiz 9y ago
Devil's advocate: there's more to keeping email safe than just not allowing JavaScript. Most browsers let you have up to 255 drop shadows on a single element, which can really heat up your laptop. CSS animations can also cause havoc. Imagine loading a GIF from a server that just streams frames forever. You also don't want to immediately load images (for privacy reasons), and you probably also want to ban audio and video while you're at it. In a web email client, you don't want the styles of the email to affect the chrome of the app. <iframe>, <object>, and <embed> lead to a world of bad ideas. <base> and <dialog> could potentially cause unusual issues. I can't think of anything off the top of my head, but I'm sure data URIs could be abused somehow (data URI-encoded SVGs something something loading content dynamically?). CSS can cause problems, too. @import could cause privacy issues, as could @font-face. If images are not pre-downloaded, @media and @page could reveal when you print a message and @supports could leak details about your mail client. `position: fixed` would need to be banned outright I'd think, if the message isn't sandboxed in an iframe. HTML5 as a whole is designed for building applications, not for making pretty messages. You want to have a subset of HTML5, but not too strict of a subset. Some APIs (e.g., @font-face) probably can't be used as-is and need a replacement. And of course, it all needs to be somehow backwards-compatible.
- JdeBP 9y ago
  If one is reading mail, a good quality MUA will not be "loading a GIF from a server" in the first place. The content to show should be all right there in the message to start with, included using multipart/, or it does not get shown. * http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExternalContent http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExtern...

bastawhiz 9y ago

Devil's advocate: there's more to keeping email safe than just not allowing JavaScript. Most browsers let you have up to 255 drop shadows on a single element, which can really heat up your laptop. CSS animations can also cause havoc. Imagine loading a GIF from a server that just streams frames forever. You also don't want to immediately load images (for privacy reasons), and you probably also want to ban audio and video while you're at it. In a web email client, you don't want the styles of the email to affect the chrome of the app. <iframe>, <object>, and <embed> lead to a world of bad ideas. <base> and <dialog> could potentially cause unusual issues. I can't think of anything off the top of my head, but I'm sure data URIs could be abused somehow (data URI-encoded SVGs something something loading content dynamically?). CSS can cause problems, too. @import could cause privacy issues, as could @font-face. If images are not pre-downloaded, @media and @page could reveal when you print a message and @supports could leak details about your mail client. `position: fixed` would need to be banned outright I'd think, if the message isn't sandboxed in an iframe. HTML5 as a whole is designed for building applications, not for making pretty messages. You want to have a subset of HTML5, but not too strict of a subset. Some APIs (e.g., @font-face) probably can't be used as-is and need a replacement. And of course, it all needs to be somehow backwards-compatible.

JdeBP 9y ago
If one is reading mail, a good quality MUA will not be "loading a GIF from a server" in the first place. The content to show should be all right there in the message to start with, included using multipart/, or it does not get shown. * http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExternalContent http://jdebp.eu./Proposals/gnksoa-mua.html#NoAutoFetchExtern...