Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
AMPHTML Email
See original GitHub issueMotivation
Email is a cornerstone of many consumer and enterprise workflows. However the content that is sent in an email message is still limited — messages are static, can become out of date, and are not actionable without opening a browser.
Our goal is to enhance and modernize the email experience through added support for dynamic content and interactivity while keeping users safe. We propose to do this by allowing email publishers to embed AMP directly in a message body as a new MIME part—text-x-amphtml—which will be rendered by email clients (with graceful fallback to non-AMP content). Our proposed name for this project is “AMPHTML Email”.
Compared to websites, email is a different user context with different models of privacy and security. For example, phishing is a major concern for email. To maintain users’ expectations of security and privacy, we’ll only allow a conservative subset of AMP functionality. To enforce this, we propose adding a new AMPHTML email validation spec identified by a new attribute on the document element: amp4email. This is similar to the technique used by the AMPHTML Ads project which introduced its own spec that uses the attribute amp4ads .
Requirements
- Supports modern phishing and spam mitigation strategies
- Supports preserving privacy expectations of modern email providers
Proposed design
A minimal document:
<!doctype html>
<html ⚡4email> <!-- `amp4email` also accepted. -->
<head>
<meta charset="utf-8">
<style amp4email-boilerplate>body{visibility:hidden}</style>
<script async src="https://cdn.ampproject.org/v0.js"></script>
</head>
<body>
Hello, world.
</body>
</html>
Note the lack of a <link rel=canonical> element compared to the traditional AMP spec. This is because an AMP email doesn’t have a canonical email. The boilerplate CSS is also simpler.
After a security review, the components below have been found to be secure in an email context:
Dynamic content
- amp-form
- amp-selector
- amp-bind & amp-state
- amp-list
- amp-mustache
Presentation
- amp-accordion
- amp-carousel
- amp-sidebar
- amp-image-lightbox
- amp-lightbox
- amp-fit-text
- amp-timeago
Media
- amp-img
- amp-anim
Caveats
- All fetchable attributes like
srcandhrefmust be static (i.e. cannot be mutated byamp-bind) so they can be inspected by spam/phishing filters - All network requests must be proxy-able to prevent leaking of users’ IP address, setting cookies, etc.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:232
- Comments:113 (27 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
AMP is unnecessary. By embracing it, it results in a de facto ‘ownership’ of the lingua franca of the internet by a huge, monolithic corporation that already has an outsized influence on culture and technology.
I’d rather have my plain old ‘unsafe’ internet.
This is huge given how consumer behavior has changed over years, but email has not.