Editor’s note: The below was originally posted on gregable.com by Greg Grothaus, Software Engineer, Google
Google just officially launched AMP Email, with support from other webmail providers. I work for Google on AMP and worked on some aspects of this project. I thought I’d add my own thoughts on the announcement. My opinions are my own and not those of my employer.
The press has focused on the user experiences in AMP Email. This makes total sense, given the audience. My take, however, is that the more interesting development is the step towards standardizing of HTML Email. Let me explain.
Let’s take a step back and consider non-amp HTML email. The basic idea is that the sender provides two variants of each email using MIME type encoding. Here’s a simplified example:
From: "Senders Name" <sender@gregable.com> To: "Recipient Name" <recipient@gregable.com> Content-Type: multipart/alternative; boundary="bdac7942f697eecfbdac7942f697eecf" --bdac7942f697eecfbdac7942f697eecf Content-type: text/plain; Some text content. --bdac7942f697eecfbdac7942f697eecf Content-type: text/html; Some bolded html content. --bdac7942f697eecfbdac7942f697eecf
An email client is free to choose which of these 2 alternatives to display and more importantly how to render the bytes.
An email client is not itself a web browser, even if it runs within one. Allowing arbitrary HTML email to run with the full API of a web browser simply fails. The first thing most marketers would do is add a redirect to their own site the moment the email loads.
Simply mitigating redirects and similar is insufficient. The privacy of the user reading the email must be protected. In the case of Gmail and many other webmail clients, the client actively prevents the sender from learning the user’s IP or browser fingerprint. This is fundamentally different from how web browsing works, so browsers fail to provide protection. When browsing, your browser sends your IP address, browser name, and capabilities along to every page that you visit.
A webmail client must then contort it’s presentation of HTML, a language not designed with email in mind. Webmail clients only have two ways of doing so:
- Show only the text version of an email.
- Modify the HTML before delivery such that the resulting document is safe.
Webmail clients do both. In some cases, the client falls back to text. In most cases, it modifies the HTML.
This is typically called “HTML sanitization”. For some examples:
- <script> tags removed completely.
- Image URLs are rewritten to load the images from the webmail provider.
- Some or all CSS is removed completely.
In many cases, the HTML gets horribly mangled and then shown to the user completely broken, but at least it does not violate the user’s privacy expectations.
A sender must ensure that the email sent will not arrive completely broken.
Each webmail provider sanitizes HTML emails slightly differently. In some cases, not so slightly. The rules for the sanitization are necessarily complex, as HTML is complex. As a result, the documentation describing these rules is often poor or even missing. It’s almost never the case that two email providers will treat the same email the same way.
Some references to support my point:
Webmail Rendering Explained: Why Preprocessors are the enemy:
“Most preprocessors err on the side of being overly restrictive and remove anything with even the slightest potential to affect the layout of their email client.”
Developing HTML Emails for Gmail: 12 Things You Must Know:
“Many email developers know how tricky it is to develop HTML emails for Gmail – it’s one of the more temperamental clients out there (although it’s no Outlook).”
“If you’re a web designer, you’re probably used to testing web pages in a few different browsers, like Internet Explorer, Mozilla Firefox, and Safari. And you’re probably familiar with a few annoying inconsistencies between all the browsers, and you have a couple hacks to make things look right. For email design, multiply all that by ten. There are tons of email applications out there that you need to test on, and they all render HTML email in their own annoying ways.”
See Mailchimp’s Email Client CSS support matrix to get an idea of the mess you can expect if you want to write an HTML email.
Beyond documentation, none of the major webmail companies provide testing tools. This has resulted in a small industry of services that exist simply to help you test whether or not an HTML email will render correctly. Try this query to get an idea: [html email testing tool]. These services work by maintaining accounts on major mail providers, automating test emails, reverse engineering the sanitization layers, and staying on top of changes.
AMP improves on some of these problems.
With AMP Email, there is a specification for an email sender to develop against. That specification is complicated and evolving, like the others. The documentation is incomplete, like the others.
What’s different about the AMP Email spec?
There is a single specification which multiple webmail companies are implementing. The announcement lists Gmail, Yahoo Mail, Outlook.com, and Mail.Ru. The list is incomplete, but is a solid start.
Open source tooling can validate an AMP Email. Developers get detailed error codes including line numbers and documentation links. The tooling can be run locally as an NPM library or online:
If a developer meets the specification, the promise is that the email will be correctly rendered in every supporting html mail client using every modern browser. The spec and the web mail implementations continue to guarantee the privacy of the user reading the email.
That’s the punchline as I see it: AMP Email is a consistent format that “just works” for developers trying to send HTML email.
There are a few other concerns that have been raised, but I feel some of them are uninformed, while others may be valid:
This is a proprietary format
The specification is open-source and is just a subset of HTML, but it is managed by the governance of the AMP Project. Also note that in effect HTML Email is a set of proprietary formats. No web mail provider supports arbitrary HTML.
Email should be plain text
Perhaps. There is certainly an argument to be made here. I personally suspect that users may be making the wrong dichotomy here: not that HTML email is bad, but junk email is bad and junk email tends to use HTML formatting.
Furthermore, AMP HTML Email does not change the story. No mail provider that currently does not support HTML email also does support AMP HTML email.
HTML email usage seems to be increasing. Simply bolding text or adding an image to an email makes it HTML email, which can be a better experience for most users.
AMP HTML Email still includes a text fallback mime type for users who prefer it.
Yet another format
The concern here is that since not all email clients support AMP HTML email, this effectively added 1 new mime format in each email, rather than simplified anything. This is a valid concern. However, any proposal that requires all email providers to make a simultaneous change is doomed to fail. In the long run, hopefully this simplifies and improves the state of email.
Posted by by Greg Grothaus, Software Engineer, Google