The problem with monopolies is that nobody else has a choice. If Outlook or Yahoo were to fail to adopt the proprietary Gmail standard, they would eventually end up incompatible with the now-proprietary format of email. Whilst AMP4Email can fall back to HTML, the reality, as with text-only emails after HTML, that many providers will not bother sending multiple formats.
Your team has repeatedly refused to address criticisms of AMP from users and the community at large, and continued forward with a program that nobody wants[1]. There's still no way for someone to opt out of AMP as a whole except to use a search engine that doesn't support it, and Gmail seems to lack an AMP switch in settings, so I'm guessing you currently have no plans to let Gmail users escape it either.
... Microsoft and Yahoo think it's a good idea and want to support it. There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.
> sit around in the gutter while the rest of the web gets more multimedia and more performant
I (sincerely) appreciate reminders like this of just how much online opinions and experiences vary.
My sense of the last few years of web changes is that performance is mostly a product of script-blocking or AMP-degraded functionality, and new multimedia is mostly a user-hostile attempt to boost revenue. Whether it's five-point stories broken across five page loads, Reddit's "use our app" links breaking in AMP, or Techcrunch's insane scroll-down-to-redirect-to-homepage layout, the last ~3 years of web development are full of changes I find actively negative.
I understand the fight over something like AMP for email much better when I remember how far from universal that is. It's not really a surprise there's so much disagreement over what to do next when there's this much divide over what's working well at present.
AMP seems less like a response to 'the web is slow' and more a response to 'people who are tired of slow websites are using content blockers so we need an alternative so they don't block our ads'.
Some HTML in email is fine, I would say the subset that can be expressed by markdown. Making text bold, italic etc should be possible. The real problem I have is how limited email HTML/CSS and email clients are compared to the web, so that every "rich" email will use table layouts that render terribly on mobile.
Technically email is plaintext, though for the definition you aspire towards, it was in the early days. But then various RFC's added this and that and now email processing/sanitisation is scary.
But then email is one large unsanitized input that has so many rules to be applied, what could go wrong.
That's why email attachments alone are an utter MIME-field when it comes to security.
Not seen that, watching now (about half way thru) and nice to retouch upon a feild I've not working in for many years and seeing how not much has changed. Equally a little depressing, to see the same types of problems 10 years on.
> There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.
"The rest of the web" is the ad-laden, tracker-infested, bloated gutter of the internet. Email is (was?) a little morsel of the old open internet (along with RSS/podcasts) that has not yet drowned in the morass.
More performant then text? What are you comparing it to smoke signals FFS? And let me see if I understand you correctly, you _WANT_ multimedia in your emails?
What is the point? To send miniature versions of web-pages?!?
Google is looking for alternative channels to sell ads through. Adding more complicated media to email increases the type of ads that can be sold. It won’t be right away, but it’s coming.
As their users spend more time with voice assistants and less with search result pages, Google needs to make up for those losses somewhere else. If they don’t, their revenue growth will end or invert, the stock price will drop, and the amount of money they can pay all of their employees will significantly decline.
For all of the messaging platforms Google tried to build and messed up, it is a real possiblilty that Google could end up killing Gmail through management screw ups.
I favor this view of outcomes. The backlash caused by AMP in the first place was loud, but small. More people seem to be catching on with the negatives of it... AMP for email may not be the downfall of Gmail, but it opens new decision pathways that could be very harmful for the platform, such as inserting ads into private email conversations.
None of those "Advantages" were advantageous to the end user. This only benefits Google or other corporations, and anything that benefits them harms me.
With respect, "anything that benefits corporations harms me" is a weird attitude.
AMP in email could, hypothetically, allow me to hit the "checkin to my flight" button for a Southwest flight directly from my confirmation email without having to bump over to their website. That's cool, convenient, and simplifies my life. It also benefits the corporation (their resource allocation is easier if they have a firm count of flyers) and it benefits Google (I'm more likely to use an email client that facilitates this).
The business world is full of win-wins, and this has the potential to be one of them.
Email has in some ways sat around in the gutter but media reasons are not why. The protocols are insanely complex and archaic and you need about 20 bits of software to actually run an email server. And then its all completely insecure because email was never built with end to end crypto.
imap is so insane that every email provider reinvented it to have a sane api for their web client and app. Fastmail also created JMAP to have a standard json api for email.
How could email possibly be more performant? Its just a few blocks of text. I click on the email and it loads instantly because its already downloaded.
This effort destroys half of what makes email useful. I know that moving forward, I won't accept amp emails. If anyone sends me one, I'll just have to tell them to please send me a plain-text copy if they really want me to see it.
On the plus side, this could make spam much easier to detect: if it's amp-based, then it's most likely to be spam.
> if it's amp-based, then it's most likely to be spam.
Which is particularly funny because amp URLs have also become a major tell for spam. Want your sketchy sign-in page to come from a legitimate-looking domain? Just set it up with AMP and all the "check the pre-.com URL" rules people know will completely fail them!
I wonder if AMP for email will produce the same hell of broken redirects that it's created for webpages?
And in 9-12 months, HTML fallback will become optional for senders who want to "optimize" their content. And to prevent "inconsistent user experiences, which are causing user confusion."
Senders can include or not include any MIME types they want; that's just how email works. Though it seems unlikely they'd skip HTML fallback, since not every email client connected to Gmail is necessarily going to support AMP.
I guess that the HTML fallback is not cost free to create. I bet that some of them will be links to the website, like the "read this message on the web" links that are almost the only fallback we have from complex layouts now.
That's what the specification says they should. Just like HTML emails should not have an empty "text/plain" as an alternative to their main "text/html" content, but some mailers do that anyway.
And I do mean empty, not absent, so MUAs don't even try to convert the HTML to plaintext.
Or sometimes, the plaintext version is buggy, eg. because the mailer forgot to remplace {{template variables}}. Or because it sent a boilerplate text. Or the content of a mailing that was sent years ago. (All of these are true stories, I got emails like these.)
The conclusion being that if some format (AMP, HTML, ...) becomes prevalent, developers will stop caring about other formats.
Yes, I disallow HTML as well. Well, technically, I don't allow HTML to render. If the email is important, then I'll read the HTML source myself and extract the parts that are important.
No, I actually use Thunderbird. I disallow HTML for security reasons. It lets me avoid having any remote resources (such as images, etc.) load and eliminates the possibility of any sneaky JS or somesuch executing.
The future of email should be a deprecation of email. Email is an archaic system, where different clients implement their own versions of rendering or sanitizing email. Some platforms don't even include proper email headers. Now there's this 'AMP' that's being shoved up our throats. Not to mention the nuances around deliverability like spf records and dkim. There's also the issue of spam.
I'd love to see email go away and more modern messaging platforms take its place. Having worked on apps and platforms that work with and parse email, email is not the future.
Having different clients is probably an anti fragile mechanism of email. It literally helps keep it around and mostly working.
I think the single worst thing to happen to email is the consolidation to so few vendors, ironically. This move is not changing my view. Does make me think heavily of ditching Gmail as a client. I was using emacs, but can't with advanced protection turned on. :(
I really don't want to go back to the days of having multiple incompatible mail systems. The fragmented instant messaging landscape is terrible enough as it is.
I'm worried that if email gets deprecated, it will be deprecated by a proprietary service because it's more convenient for users (or worse: several incompatible services, most of which proprietary).
Like IRC mostly got replaced by Slack and Discord.
I don't disagree that there's room to move away from email, but how do the current crop of messaging services promise to overcome the problems you mentioned? They all seem as varied in their implementations as you suggest email is.
I'll also add that I think if something were to replace email, hopefully it would incorporate the slow response expectation of it. IM etc usually implies an expectation of an immediate answer; the length and expectation of not receiving an immediate reply afforded by email is immensely valuable.
reply