[jchw]

>So now email clients need to implement a javascript engine as well as an html engine?

Webmail can do JS. Clients using full HTML engines like MSHTML, Gecko or Webkit shouldn't have an issue either. Text-based clients are the obvious exception, and they should still be rendering the same plaintext mail they've always been rendering.

Clients can also not implement AMP for e-mail, which I imagine is going to be the case for plenty of them.

>For what benefit to users?

Better interactivity in e-mails. Replying to e-mails is notoriously tricky to get right and often confusing, due to interactions with email threads, CC/BCC, address spoofing, etc. Interactivity via hyperlinks is acceptable but not ideal, especially for services that are actually performing operations on a GET request, which I'd argue is unwise. But also, hyperlinks in e-mails often contain sensitive tokens, which are easy to accidentally forward.

AMP interactions should be free of unrelated junk that e-mail replies would contain and can offer more functions. As for security, at the very least, Gmail strips off AMP during forwarding, which should make it safer to include tokens for interacting with e-mails in AMP payloads. Obviously that does no good for purely sensitive mail like password reset, but it's still an improvement.

>At what cost to users?

HTML and plaintext e-mail should continue to function for the foreseeable future.

[hn23]

The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.

Plaintext mail should not just continue to function. A plain text mail should be default.

[jchw]

>The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.

No, there’s certainly complications regardless of client. For example, verifying the reply email is actually from the user, handling top posting vs inline replies, etc. Lots of these systems work around issues by adding things like “REPLY BELOW THIS LINE” and instead of CCing multiple users, sending individual emails with their own personal reply-to addresses. All in all, I’d be happy to see that mess disappear, for things other than mailing lists where the actual entity is an email in the first place.

>Plaintext mail should not just continue to function. A plain text mail should be default.

Well, I just do not agree with that.

[hn23]

Seems you try using mail for a purpose it was not invented for? I think mail should be what it is: an electronic analogon for real mails. If you send "real" mail you have no control how/when/if I am going to reply or even read it. If you want this type of control, use another tool. I guess this is why Jehovah's Witness ring the door but do not send mail;)

>> Plaintext mail should not just continue to function. A plain text mail should be default.

> Well, I just do not agree with that.

I referred to the fact that you mean it "should" work for a foreseeable future. I mean it should work with plaintext for ever without require a user to parse $scriptLanguageOfTheYear relying on framework $fancyShitOfTheYear. We have been there - remember IE6.

[delusional]

If your only interaction with email is outlook, the you outlook is understandable. But I don't get how replying to an email is "notoriously tricky to get right".

Why do I need interactivity in my emails? Is that what emails are good at?

[manigandham]

Interaction should be handled by linking to a site where that interaction can take place. Automatic logins are already handled by services that know how to do it so it's as frictionless as possible.