[tpetry]

AMP for email is targeting a completely different topic than the issues listed here and in the article. And i am shocked everybody is simply not seeing them with their amp4web hate.

Amp for email is completely different than amp for web and is a very good solution: 1. Coding emails is really really hard. Every client is rendering emails differently, and Outlook is a beast with every version rendering differently. Amp for email is standardizing a subset of email and css every client should support so email building will be easier. 2. Email is completely different than the web. You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email. You will get features in emails compared to the web so they will get usefully again.

And i am afraid nobody is seeing this and only hating amp4web‘s hiding if the real urls etc.

[ori_b]

> You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email.

Alright, you've convinced me: AMP for email needs to be killed.

[WrtCdEvrydy]

> Embedding videos?

Let me open this email... oh noes, it's autoplay video.

> Slideshows for products?

Yes, more marketing garbage!

> Interactivity like forms?

Your password is about to expire, change it below or some garbage that will only make shit more insecure.

> Display realtime information

Blow me.

[hexo]

Exactly. Couldn't have been said better. Kill AMP completely and don't even think about touching email with that.

[ocdtrekkie]

amp4email is far worse and more dangerous than amp4web, and that's why privacy respecting email services are so opposed to it. Tutanota here, and FastMail who posted about it when it was first announced.

AMP isn't a subset of HTML, it's it's own proprietary fork of HTML. It's not saying an img tag is okay, it's tell you to use an amp-img tag.

[SquareWheel]

>AMP isn't a subset of HTML, it's it's own proprietary fork of HTML.

This is another misunderstanding. HTML allows custom tags. This is built into the spec. AMP is plain and regular, standards-compliant HTML.

[callahad]

It is impossible to use AMP as a standalone Custom Element library and still validate as AMP. Valid AMP is required to dynamically load the library from Google's unversioned CDN.

[SquareWheel]

That's true. But it's still valid HTML. It's most definitely not a fork of anything.

>unversioned CDN

Isn't the filename versioned (v0.js)?

[callahad]

Not really. The project leaders have explicitly stated that the content of the script at that URL is subject to change at any time, and thus users are prohibited from locking it to an audited, known version with an SRI hash.

[SquareWheel]

I see. Thanks for the clarification. That is pretty poor practice.

I guess v0 might imply "beta" and thus not have stable API naming yet. But still, it's clearly being used in production at this point.

[ocdtrekkie]

I think you are misunderstanding my point.

An img tag doesn't work on an AMP page. It has to be an amp-img. Every standard HTML tag is invalid in AMP content, as you must use a customized AMP flavor of HTML.

Whether or not it returns valid as HTML markup isn't really relevant: The point is it's an entirely different, incompatible, markup, from what a normal browser knows how to interpret and use, and if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?

[joshuamorton]

That's not true, only tags that make web requests or do dynamic things are amp'd. You still use div and button and style and span and whatnot.

[SquareWheel]

There is an important difference between saying it is invalid html, and it is invalid amp markup. An img tag will work like normal. It just won't be a valid AMP page any longer.

>if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?

It wouldn't. <noscript> tags are needed for that. But Javascript is a web standard, and this is the correct way to create new elements.

[josteink]

> Email is completely different than the web. You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email.

This alone is the reason I oppose AMP email.

I want email to be a simple, static text-based communication platform.

None of that full HTML application-stack bullshit.

[cromwellian]

Email already has HTML in it and has for decades, hell, there were startups dedicated to it like Zaplets et al.

AMP doesn't enable HTML email, it was already enabled by Outlook 97.

[josteink]

But not HTML applications. JavaScript is banned. Dynamic content is banned.

This is good. We should aim to keep it this way.

[cromwellian]

Actually, you're wrong. Zaplets made this work somehow, and were funded to the tune of $90+ million in VC money. Perhaps they just used an iframe or <applet>, but never the less, Zaplets offered interactive HTML forms inside of mail that worked in Outlook. (https://www.forbes.com/forbes/2000/0612/6514218a.html#224241...) AMP Email is largely following what the Outlook 97 client was capable of.

There's no apriori reason why a federated messaging system needs to be non-interactive. It's possible to support both immutability and dynamism. You're making assertions that something should be a certain way without actually justifying it.

You could at least provide some formal justification, like you want Email to be an immutable ledger or something. But the idea that Email can't evolve and change and should stay exactly the way it was, pretty much assures its death in the dust bin of history, the same way we lost USENET, LISTSERV, or even XMPP. Old standards didn't evolve quickly, users wanted silly features while neckbeards said don't violate purity of my abstraction.

And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.

[dngray]

> But the idea that Email can't evolve and change and should stay exactly the way it was, pretty much assures its death in the dust bin of history, the same way we lost USENET, LISTSERV, or even XMPP. Old standards didn't evolve quickly, users wanted silly features while neckbeards said don't violate purity of my abstraction.

Also the things you've mentioned there are different things. XMPP was never as widespread as email and is not in any way related to the other two. I am hoping Matrix picks up here.

LISTSERV is simply mailing list software, these do exist today as they did and are used by many open source projects. The most popular one being https://en.wikipedia.org/wiki/GNU_Mailman

USENET, does still exist, particularly for binaries. It's decline was mostly because of the cost to run the services, spam and the fact that smaller web forums were an alternative.

> And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.

Not in business it's not, particularly where both parties want to have a conversation and not let those platforms in on the conversation. That is the majority of business and government conversation.

Email is not going anywhere.

[cromwellian]

You don't have to explain what those things are, I've been on the internet since the 80s, and my teen years were literally forged on those platforms. Yes, smaller web forums killed USENET, and the reason they did so is that it was far easier to evolve controls for spam, for toxic posters, for adding features like voting, inline images, inline markup, custom headers/landing/etc than it was on a federated system like USENET. When the Web arrived, user expectations in terms of the ease of use and richness of the interface changed, which is exactly what's happening with email.

If business really wanted end to end un-eaves-droppable confidentiality they would have mandated S/MIME years ago. The very nature of a store-and-forward protocol without end to end encryption pretty much guarantees you don't have confidentiality unless the entirely of your communication is within your organization, and even then, it's not really secure because most business organizations did not run internal encryption.

The number of firms outsourcing to cloud services continues to rise.

Yes, Email is not going to die for internal business communication, but it will transform, and interactivity and dynamism are inevitable. Lotus Notes is a great example of this. Email is often used for workflow, for updates of real time information, and spamming people with status messages that link to dashboards is a productivity hit and produces information overload.