3 ms·

I don't know the technical details of what Google is planning, but if they build something that eases the pain of building cross platform HTML emails, that's a

I don't know the technical details of what Google is planning, but if they build something that eases the pain of building cross platform HTML emails, that's a welcome innovation in my opinion. Building emails that "work" even just okay is a ridiculously hard task. Every company I've been at has made some attempt with mediocre results at best (oh, you're using _Outlook_?). I'm not holding my breath for something good to come out of this, though. This could just as easily be a terribly executed product. But I'll try to be an optimist, because what we have now is outright trash.

gerdesj 9y ago
"but if they build something that eases the pain of building cross platform HTML emails" On the other hand, if HTML is excluded then the message gets through without scope for mischief.
- bastawhiz 9y ago
  HTML emails are here to stay, and the billions of dollars that companies pour into designing, building, and sending them are proof of that. Given the constraint that we're stuck writing and consuming them, I'd rather have a technology that does a good job than a technology that makes me want to boil my laptop. If you're afraid of HTML, by all means please check your email from a sandboxed VM in the terminal. But some poor chump is still going to be toiling away to make the latest Pottery Barn newsletter look great on a Blackberry, so we'd might as well build better tools.
zeroimpl 9y ago
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...

gerdesj 9y ago

"but if they build something that eases the pain of building cross platform HTML emails" On the other hand, if HTML is excluded then the message gets through without scope for mischief.

bastawhiz 9y ago
HTML emails are here to stay, and the billions of dollars that companies pour into designing, building, and sending them are proof of that. Given the constraint that we're stuck writing and consuming them, I'd rather have a technology that does a good job than a technology that makes me want to boil my laptop. If you're afraid of HTML, by all means please check your email from a sandboxed VM in the terminal. But some poor chump is still going to be toiling away to make the latest Pottery Barn newsletter look great on a Blackberry, so we'd might as well build better tools.

zeroimpl 9y ago

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...