编辑注:以下内容最初发布在 gregable.com上,作者为 Google 软件工程师 Greg Grothaus
Google 刚刚正式推出了 AMP 电子邮件,并得到了其他网络邮件提供商的支持。我在 Google 负责 AMP,并参与了该项目的部分工作。我想就该公告发表一下自己的看法。我的观点仅代表我个人,不代表我的雇主。
媒体关注的是 AMP 电子邮件中的用户体验。鉴于受众,这完全合理。然而,我认为更有趣的进展是朝着标准化 HTML 电子邮件迈出的一步。让我解释一下。
让我们后退一步,考虑一下非 AMP HTML 电子邮件。基本思路是发件人使用 MIME 类型编码提供每封电子邮件的两个变体。以下是一个简化的示例
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
电子邮件客户端可以自由选择显示这两个备选方案中的哪一个,更重要的是如何呈现字节。
电子邮件客户端本身不是网络浏览器,即使它在浏览器中运行也是如此。允许任意 HTML 电子邮件使用网络浏览器的完整 API 运行根本行不通。大多数营销人员会做的第一件事就是在电子邮件加载的那一刻将其重定向到自己的网站。
仅仅缓解重定向和类似问题是不够的。必须保护阅读电子邮件用户的隐私。对于 Gmail 和许多其他网络邮件客户端,客户端会主动阻止发件人了解用户的 IP 或浏览器指纹。这与网络浏览的工作方式有着根本的不同,因此浏览器无法提供保护。在浏览时,浏览器会将你的 IP 地址、浏览器名称和功能发送到你访问的每个页面。
然后,网络邮件客户端必须扭曲其对 HTML(一种并非针对电子邮件设计的语言)的呈现方式。网络邮件客户端只有两种方法可以做到这一点
- 仅显示电子邮件的文本版本。
- 在发送之前修改 HTML,以便生成的文件是安全的。
网络邮件客户端会同时执行这两种操作。在某些情况下,客户端会退回到文本。在大多数情况下,它会修改 HTML。
这通常称为“HTML 清理”。以下是一些示例
- 完全删除<script> 标记。
- 图像 URL 会被重写,以便从网络邮件提供商加载图像。
- 部分或全部 CSS 会被完全移除。
在许多情况下,HTML 会被严重破坏,然后向用户显示完全损坏的内容,但至少不会侵犯用户的隐私预期。
发件人必须确保发送的电子邮件不会完全损坏。
每个网络邮件提供商都会以略有不同的方式清理 HTML 电子邮件。在某些情况下,差异很大。清理规则必然复杂,因为 HTML 本身就很复杂。因此,描述这些规则的文档通常很差,甚至缺失。两种电子邮件提供商以相同方式处理同一封电子邮件的情况几乎不存在。
一些支持我观点的参考
“大多数预处理器倾向于过于严格,并移除任何可能影响其电子邮件客户端布局的元素,即使是影响最小的元素。”
为 Gmail 开发 HTML 电子邮件:您必须了解的 12 件事:
“许多电子邮件开发人员都知道为 Gmail 开发 HTML 电子邮件是多么棘手——它是目前最不稳定的客户端之一(尽管它不是 Outlook)。”
“如果您是网页设计师,您可能习惯于在一些不同的浏览器中测试网页,例如 Internet Explorer、Mozilla Firefox 和 Safari。而且您可能熟悉所有浏览器之间的一些烦人的不一致之处,并且有一些技巧可以使事情看起来正确。对于电子邮件设计,将所有这些乘以十。有大量电子邮件应用程序需要您进行测试,并且它们都以自己烦人的方式呈现 HTML 电子邮件。”
请参阅 Mailchimp 的电子邮件客户端 CSS 支持矩阵 ,了解如果您想编写 HTML 电子邮件,可能会遇到哪些问题。
除了文档之外,没有一家主要的网络邮件公司提供测试工具。这导致了一小部分服务行业的存在,这些服务的存在只是为了帮助您测试 HTML 电子邮件是否会正确呈现。 尝试此查询以了解情况: [html 电子邮件测试工具]。这些服务通过维护主要邮件提供商上的帐户、自动化测试电子邮件、逆向工程清理层以及随时了解更改来工作。
AMP 改进了 部分 这些问题。
使用 AMP 电子邮件,电子邮件发件人有一个规范可以针对其进行开发。 该规范 很复杂,并且像其他规范一样在不断发展。文档不完整,就像其他文档一样。
AMP 电子邮件规范有什么不同之处?
有一个规范,多个网络邮件公司正在实施。公告列出了 Gmail、Yahoo Mail、Outlook.com 和 Mail.Ru。该列表不完整,但是一个坚实的开端。
开源 工具 可以验证 AMP 电子邮件。开发者可以获取详细的错误代码,包括行号和文档链接。该工具可以作为 NPM 库 或在线本地运行
如果开发者符合规范,那么承诺是电子邮件将在使用每个 现代 浏览器的每个 支持 html 邮件客户端中正确呈现。规范和网络邮件实现将继续保证阅读电子邮件的用户的隐私。
在我看来,这是关键所在: AMP 电子邮件是一种一致的格式,对于尝试发送 HTML 电子邮件的开发者来说“有效”。
还有一些其他问题已经提出,但我认为其中一些是无知的,而另一些可能是有效的
这是一种专有格式
该规范是开源的, 只是 HTML 的一个子集,但它由 AMP 项目的治理管理。还要注意,实际上 HTML 电子邮件是一组专有格式。没有网络邮件提供商支持任意 HTML。
电子邮件应为纯文本
也许吧。这里肯定有争论的余地。我个人怀疑用户可能在这里做出了错误的两分法:不是 HTML 电子邮件不好,而是垃圾邮件不好,而垃圾邮件倾向于使用 HTML 格式。
此外,AMP HTML 电子邮件并没有改变这一说法。当前不支持 HTML 电子邮件的邮件提供商也不支持 AMP HTML 电子邮件。
HTML 电子邮件的使用似乎正在增加。简单地加粗文本或向电子邮件添加图像会使其成为 HTML 电子邮件,这对于大多数用户来说可能是一种更好的体验。
AMP HTML 电子邮件仍然包含一个文本备用 MIME 类型,供喜欢它的用户使用。
又一种格式
这里的问题在于,由于并非所有电子邮件客户端都支持 AMP HTML 电子邮件,因此这实际上在每封电子邮件中添加了 1 种新的 MIME 格式,而不是简化任何内容。这是一个有效的问题。但是,任何要求所有电子邮件提供商同时进行更改的提议注定会失败。从长远来看,希望这会简化和改善电子邮件的状态。
由 Google 软件工程师 Greg Grothaus 发布