电子邮件开发的 7 个误区

已发表: 2016-10-25

1971 年，电子邮件最初是一种纯文本的 1:1 通信方式，当时它是由 Ray Tomlinson 构思的。几十年来，电子邮件不断发展，从早期电子邮件的纯文本版本转变为 HTML。将电子邮件推向未来的是电子邮件开发人员，他们在严格的范围内使用创造性的技术。

在那个时候，电子邮件开发人员创建了所有类型的“最佳实践”来帮助其他人开始使用电子邮件编码，或者提醒那些处于战壕中的电子邮件开发人员可以做什么和不可以做什么。

我们今天在这里提醒电子邮件开发人员，最佳实践不应被视为静态的。他们改变。 1990 年代后期最适合电子邮件开发人员的做法在 2010 年代中期不再适用。

以下是七个流传已久的电子邮件开发误区，以及为什么是时候让它们停下来了：

误区一：电子邮件的宽度必须为 600 像素。
误解 2：您必须只使用标准系统字体。
误区 3：只使用 Transitional DOCTYPE。
误区四：需要使用属性选择器。
误区 5：电子邮件中的所有样式都必须内联。
误区 6：不要在电子邮件中使用背景图片。
误区 7：所有电子邮件客户端的电子邮件必须看起来相同。

误区一：电子邮件的宽度必须为 600 像素。

在手机和平板电脑变得司空见惯并且电子邮件仅仅是桌面应用程序之前，最佳实践规定所有电子邮件的宽度不应超过或小于 600 像素。为什么正好是 600 像素？当时最常用的电子邮件客户端（HoTMaiL、Yahoo 和 Outlook）的视口大小约为 500-550 像素。将电子邮件宽度设置为不超过 600 像素将允许电子邮件中的水平滚动尽可能少。

那个 600 像素的规则一直存在。即使今天有更多的设备可以满足，所有设备都有不同的屏幕尺寸，为什么我们坚持这个 600 像素规则？

这是一个容易遵守的规则，特别是如果您的电子邮件工作流程包括在 Adobe Photoshop 或 Sketch 中创建设计——您需要一个物理宽度来开始您的电子邮件设计。的确，600 像素宽度的电子邮件在桌面上的更流行的电子邮件客户端中仍然可以很好地显示。通过使用媒体查询，电子邮件开发人员可以根据订阅者用来打开的设备轻松更改电子邮件的宽度。

流体宽度解决了电子邮件开发人员需要支持的设备数量过多的问题。为了实现这一点，请使用 max-width 阻止电子邮件在较大的视口上变得太宽和难以辨认，并使用 MSO 条件语句让 Outlook 理解（因为它不呈现 max-width CSS 属性）。

Zalando 的电子邮件宽度为 450 像素——与我们习惯看到的 600 像素标准相差甚远。结合大型 CTA，看起来 Zalando 的移动友好电子邮件更适合移动人群。

电子邮件周刊 — Email Weekly 不同宽度的响应式电子邮件。查看完整的电子邮件

同时，Email Weekly 的邮件采用流体技术，最大宽度为 960 像素。它使用媒体查询根据设备宽度优雅地更改电子邮件的宽度。

根据订阅者用来打开电子邮件的客户端和设备，将电子邮件的宽度设置为 600 像素以外的最大值是有意义的。

您的订阅者在哪里打开您的电子邮件？

通过电子邮件分析，您可以找出他们打开您的电子邮件的设备和电子邮件客户端。

了解更多 →

误解 2：您必须只使用标准系统字体。

系统字体长期以来一直是用于电子邮件的安全选择。好吧，他们是唯一的选择。

另一方面，自 2000 年代初以来，网页设计师一直在尝试在网页上使用非标准字体。 2008 年，CSS 规则@font-face 终于得到了网页浏览器的支持，让网页设计师可以在他们的网站上使用非标准字体。 2010 年，谷歌推出了自己的网页字体库，供网页设计师免费使用。

由于缺乏将 Web 字体导入 HTML 电子邮件的可靠方法，电子邮件设计人员没有这样的运气。更不用说缺乏许可：当第一次创建网络字体时，没有人想过它们会在电子邮件中使用，因此网络字体的许可不包括电子邮件的使用。

尽管我们建议您在电子邮件中使用标准系统字体，但这并不意味着您不能将 Web 字体用作渐进式增强技术。在线字体库开始在其许可中涵盖电子邮件的使用。 Google Fonts 拥有 800 种免费使用的网络字体，现在正成为希望在电子邮件中使用非标准网络字体的电子邮件设计人员的首选库。

Google Android 4.4、iPhone、iPad 和 Mac 的 Apple Mail 以及 OS X 上的 Outlook 2011 和 2016 中都支持 Web 字体。这似乎不是很多，但截至今年 9 月，前五名电子邮件客户端中有四个，在市场份额上，支持网页字体——iPhone、iPad、谷歌安卓和苹果邮箱。这占 9 月份打开的所有电子邮件的 50% 以上！当然，您需要查看自己的订阅者群，但这是一个很好的指标，可以表明有多少人能够在您的电子邮件中看到网络字体。

你能看出这两封电子邮件之间的细微差别吗？左边的一个是使用网络字体，而右边的一个禁用了网络字体。 Outnet 选择了一种很棒的后备字体，它在外观和感觉上与他们的 Web 字体非常接近，展示了如何在今天的电子邮件中始终如一地使用 Web 字体。

误区 3：只使用 Transitional DOCTYPE。

HTML 文档的 DOCTYPE 告诉浏览器如何呈现页面，并用于验证文档的 HTML。

电子邮件中最常用的 DOCTYPE 是：

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

电子邮件开发人员已经养成了拥有 DOCTYPE 的好习惯，尽管一些电子邮件客户端会完全剥离 DOCTYPE 或用不同的 DOCTYPE 替换它。 Gmail、Outlook.com 和 Yahoo! 邮件是删除电子邮件中存在的任何 DOCTYPE 并将其替换为 HTML5 DOCTYPE 的电子邮件客户端之一。

在 Web 上，不同的 DOCTYPE 会改变一些 CSS 属性和 HTML 元素的呈现方式。上面的 DOCTYPE 允许最广泛的 HTML 元素，包括不推荐使用的元素，例如 <font>，它们已在电子邮件中使用。在过去的测试中，此 DOCTYPE 被证明是最可靠的电子邮件。已被证明——过去时。

这是在 HTML5 成为现在的标准之前：

 <!DOCTYPE html>

HTML5 DOCTYPE 允许使用较新的 HTML5 元素，例如 <video>，可以在电子邮件中使用。虽然并非所有客户端都能够呈现新元素或属性，但没有理由不通过更新您的 DOCTYPE 将您的电子邮件推向未来。您仍然可以将已弃用的代码与 HTML5 DOCTYPE 一起使用，但在通过验证服务进行检查时，该代码将不再有效。尽管无论您的代码有效与否，都不会在可传递性或性能方面对您的电子邮件产生影响，但检查您的 HTML 标记是否有打开的 HTML 标记可能是一个好主意，这可能会影响您的电子邮件的呈现方式。

误区四：需要使用属性选择器。

雅虎！与 Outlook 相比，Mail 是一个稍微友好的电子邮件客户端。只要我们记得，它就支持头脑中的风格。一个怪癖雅虎！ Mail 确实提供的是，它将媒体查询中的任何 CSS 语句与媒体查询之外的任何 CSS 一起呈现。对此的简单解决方法是将 CSS 语句编写为属性选择器：

 *[class=”foo”] {color:#000000; font-family: sans-serif;}

像这样在电子邮件头部编写 CSS 成为标准，因为其他电子邮件客户端也读取头部样式，读取简单的属性选择器没有问题，如上面的示例。

2015 年初，雅虎！ Mail 推出了一项更新，使其能够像任何“普通”电子邮件客户端一样阅读样式：

 .foo {color:#000000; font-family: sans-serif;}

然而，因为属性选择器在电子邮件开发中已经根深蒂固，所以看到它们仍然在电子邮件代码中出现也就不足为奇了。电子邮件开发人员只是习惯于使用它们，并且电子邮件模板经常未更新。

以前无害的属性选择器现在可能对您的电子邮件造成一些伤害，如果您的代码中确实有它们的话。如果您的电子邮件样式在 Gmail 中似乎不起作用，请检查您是否仍在样式中使用属性选择器。 Gmail 不支持属性选择器，但现在（终于！）支持 <head> 中的样式。

Yahoo! 不再需要属性选择器Mail 和 Gmail 缺乏对它们的支持，因此无需在电子邮件的 CSS 中使用属性选择器。

误区 5：电子邮件中的所有样式都必须内联。

用于布局和内联样式的表格一直是电子邮件开发的基石……永远。它们定义了电子邮件和 Web 开发之间的区别。内联样式现在对于电子邮件开发人员来说是如此普遍，对于为什么必须首先内联样式变得有点模糊。

令人震惊的是，一些网站声称需要内联样式的原因是 Outlook 和 Gmail。这是完全错误的。 [推特]

Outlook 从未遇到过电子邮件标题中的样式问题。另一方面，Gmail 做到了。 Gmail 确实是电子邮件开发人员内联 CSS 的最大原因（截至 2016 年 9 月，其市场份额为 16%）。

9 月底，Gmail 开始支持头部样式。那么我们是否需要内联所有样式？

如果您的订阅者主要使用 Gmail、iOS 甚至 Outlook，我们可以自信地说，现在是时候将您的风格转移到头脑中了。但是，如果您的大多数订阅者使用依赖于内联样式的晦涩的电子邮件客户端或国际电子邮件客户端（Yandex、Libero、Terra），您可能不得不继续使用它们。与往常一样，我们提倡在您对电子邮件进行任何重大更改时对其进行测试。

误区 6：不要在电子邮件中使用背景图片。

众所周知，背景图像很难在电子邮件中正确显示。电子邮件开发人员使用复杂的 VML 代码为他们呈现在许多版本的 Outlook 中，并且其他电子邮件客户端也缺乏对背景图像的支持。

事情是这样的：背景图像可以并且确实在电子邮件中起作用，但这是将它们融入电子邮件设计的方式。在有限的支持下，您不应将背景图片用作电子邮件设计中的关键元素，因为这会影响订阅者的体验。但是您可以在电子邮件中使用它们，就像您使用网络字体的方式一样——作为一种渐进式增强。

不在电子邮件中使用背景图片的最大原因之一是 Gmail 缺乏对 CSS 属性 background-size 和 background-position 的支持。这些 CSS 属性对于高像素密度屏幕和混合/流畅/响应式电子邮件非常重要，在这些情况下，需要对背景图像的大小和放置方式进行一定程度的控制。 Gmail 和 Inbox by Gmail 现在都支持两者，因此没有理由不尝试在电子邮件中使用背景图片。

TWO Digital Marketing 的首席电子邮件开发人员兼 2016 年电子邮件设计大会发言人 Kristian Robinson 深入探讨了电子邮件中的背景图片，如果您有灵感来解决这些问题的话。

误区 7：所有电子邮件客户端的电子邮件必须看起来相同。

电子邮件客户端呈现 HTML 电子邮件的方式略有不同。电子邮件开发人员并没有接受这一点，而是试图在众多电子邮件客户端中破解相同的电子邮件。这是一项非常光荣的任务，但它可能会导致 HTML 代码臃肿和乱七八糟，这对于管理和保持更新来说可能是一场噩梦。

寻求完美电子邮件的可能不是电子邮件开发人员，而是客户或其他利益相关者。然而，电子邮件开发人员有责任教育他们周围的人了解电子邮件开发的陷阱——为什么电子邮件客户端呈现不同，以及为什么一个电子邮件客户端中的某些东西与另一个相比高 1 个像素并不重要。

“电子邮件必须达到像素完美的时代已经过去了。” @ericlepetitsf #LitmusLive
- Chad S. White (@chadswhite) 2016 年 8 月 16 日

当尝试在电子邮件中采用新技术时，这个误区尤其有害，这些技术可能无法在 100% 的电子邮件客户端上呈现，例如 Web 字体和背景图像。这两者都是增强电子邮件的绝佳方式。如果我们不尝试在电子邮件中采用和试验新技术，我们作为一个行业将何去何从？

仅仅因为某件事多年来一直以特定的方式完成并不意味着没有更好的方法来做到这一点。现在是质疑电子邮件营销行业几十年来一直采用的规则和最佳实践的时候了。

使用 Builder 更快、更轻松地编写电子邮件

使用 Builder 加速您的电子邮件开发工作流程，Builder 是唯一专为电子邮件构建的代码编辑器。而且是免费的！

开始使用 Builder →