Live data from Hacker News

AMP for email is a terrible idea

techcrunch.com

121–130 of 483 posts

Re: AMP for email is a terrible idea

#121
post #29

Thank goodness that a bunch of clever kids are going to replace boring old SMTP n MTAs n MUAs and stuff with this bollocks: https://www.ampproject.org/ 8) email works and doesn't need fixing. It (nearly) transports more messages every day than is countable and just works. SNR - now that needs fixing and a good start would be enforcing plain text.

Email “works” but it’s ass for consistently displaying anything more than text. Marketers want to make money, and right now stuffing emails with images in favor of proper layout is the only easy way to do it. Of course google also wants all of your email googling its way through their servers.

> Email “works” but it’s ass for consistently displaying anything more than text.

That's a feature, not a bug.

Re: AMP for email is a terrible idea

#122
> “For example, imagine you could complete tasks directly in email.”

Pretty much the only task I ever want to complete from inside an email is “Unsubscribe”.

I wish clients would make it easier. Gmail does has an unsubscribe button for some emails. It would be cool if it recognized emails I consistently ignore and prompt me to unsubscribe from them.

Re: AMP for email is a terrible idea

#123

Poor frogs. The water temp just got upped a couple of degrees. Too late to jump out or not just yet? Some relief for frogs that make it out of the pot: https://mailinabox.email/ https://redmail.com/ https://protonmail.com/ https://www.fastmail.com/

Lol. Leave it to somebody on HN to reduce a problematic corporate decision to a play on existential dread.

Re: AMP for email is a terrible idea

#125
post #87
post #69

Earlier quoted context omitted.

Part of why I don't advocate for CDNs when you don't need them is because I want to build robust sites that work for years untouched. For timespans over a year, anything not on your server is brittle. Oops, CDN changed its URL/didn't update their ssl ciphers/went bust and shut down completely and now {js-framework}/{css-library} is missing and my site is broken. What an unforeseeable circumstance!

That's why I like to map one of my own subdomains to the cdn service. So everything is at cdn.example.com and if I change providers, it's just a dns record change and everything is ready, even if I want to just host my own content.

Wouldn't the paths change between providers?

Re: AMP for email is a terrible idea

#126
There are a number of threads here which seem to have been downvoted because of the perceived quality of the ideas they contain. However, I always thought that downvoting was meant to be reserved for low quality discussion, rather than disagreement. Has this changed, or was I always wrong?

Re: AMP for email is a terrible idea

#127

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…

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.

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. , , and lead to a world of bad ideas. and 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.

Re: AMP for email is a terrible idea

#128

Poor frogs. The water temp just got upped a couple of degrees. Too late to jump out or not just yet? Some relief for frogs that make it out of the pot: https://mailinabox.email/ https://redmail.com/ https://protonmail.com/ https://www.fastmail.com/

Lol. Leave it to somebody on HN to reduce a problematic corporate decision to a play on existential dread.

I wished I could take credit:

https://en.wikipedia.org/wiki/Boiling_frog#As_metaphor

Post reply on HN