HTML 和电子邮件：您应该避免的 6 个常见错误

使用 HTML 代码构建电子邮件？ 这里有 6 个你应该避免的过于频繁的错误，以便从简化、干净的电子邮件通信中获益。

错误 1. 使用过于冗长的代码

我们知道，多亏了 HTML 和 CSS，我们可以构建电子邮件结构并为其提供一种形式，或者更确切地说是一种格式，从而可以显示特定类型的字体、特定的背景颜色、图像等。

现在我们将看到 HTML 和 CSS 标签如何在某些方面执行相同的功能，并最终重叠。 让我们举一个实际的例子：在 HTML 和 CSS 中定义表格的背景颜色。

代码显示在图像中。 可以看到定义了背景色的有两点：

• bgcolor = “#e75c00”是标签表的属性；
• background-color是应用于表格的 CSS 属性。

这两个属性做同样的事情，所以它们重叠：它们在表格的背景上施加橙色（根据十六进制格式为#e75c00）。

关键点现在应该更清楚了：HTML 和 CSS 属性定义可以相互叠加。 事实上，当重新设计或改变相同的电子邮件模型时，代码通常会被执行相同功能的冗余属性所困扰。

这还不是全部。 由于内联样式可以应用于每个元素，因此也可能发生这种（反常的）情况：

浏览器（或电子邮件客户端）或多或少会像这样读取代码：

• 将灰色背景 ( bgcolor = “#efefef” ) 应用到表格
• 十应用黑色背景（ bgcolor = “#000000” ）到行
• 最后，将橙色背景 ( background-color: #e75c00 ) 应用于包含文本Hello World!的单元格！

此示例和前一个示例中的最终结果相同：橙色背景上的白色文本。

问题是在第二种情况下定义了三种不同的背景规则。 用户看到的是与单元格相关的定义，因为浏览器是按顺序读取代码的（table -> tr -> td）。 由于最后一个定义是在<td>上设置的，这正是将要显示的内容。

很明显，大部分代码不是必需的。 这不仅是因为显示的唯一背景颜色是应用于单元格的背景颜色，还因为良好的电子邮件营销的目标之一是使通信尽可能轻松。 非常冗长，冗余的代码不是轻量级的代码。

我们的建议：

• 保持代码尽可能干净
• 格式化代码时避免不必要的重复
• 优先考虑内联样式
• 尝试为通信代码构建模块化结构
• 尽量通过缩进保持代码的有序性（有几个在线服务可以做到这一点，如 HTMLformatter 或 Clean CSS），以便能够对通信结构有一个概览
• 跟踪对模型所做的宏观更改的历史记录

错误二、代码注释过多

与大多数语言一样，也可以向 HTML 添加注释。 什么是 HTML 脚本中的注释？ 它是列表中被读取和执行代码的程序忽略的一部分。

下图给出了一个注释示例：

如您所见， <!-和->之间的所有内容不仅是不同的颜色（取决于编辑程序），最重要的是，它不会显示在屏幕上。

这允许插入有关已编写代码的“服务通信”，或尚未完成或需要改进的部分的说明。

还有另一种使用注释的方法。 由于未显示开始标记和结束标记之间包含的所有内容，因此可以使用它隐藏整个页面部分，如下例所示。 事实上，我们可以看到屏幕上只有三行可见，而不是代码中写的四行。

它当然是有用的工具，但我们不能滥用它。 虽然确实没有显示注释代码，但它仍然保留在发送的通信中，从而影响了它。

我们的建议：

• 明智地使用注释，例如指示通信结构的开始和结束，或插入对开发人员有用的信息
• 不要在评论中啰嗦，最好用英文写
• 发送前删除注释代码，因为它不是用于通信目的

错误 3. 错误管理电子邮件内容

在设计电子邮件时，甚至在编写一行代码之前，最好定义某些在后续实现阶段无法修改的参数，从而在生产过程中无法修改。

其中一些参数包括：

• 邮件宽度
• 图片尺寸
• 图片数量
• 标题中使用的字体大小
• 正文复制字体大小

等等。 一个经常被忽略的参数是任何文本元素的最大击键次数。

在这一点上，你可能会反对说我们对规则的狂热是有罪的，但如此严格有两个很好的理由。 第一个是概念性的，第二个是操作性的。

在概念层面上，内容（文本、图像等）和容器（HTML 结构）是两个独立的实体，具有非常精确的层次结构，前者从属于后者。

事实上，内容应该适应容器，而不是相反。 通信的架构是在编写代码时构建的。 这定义了容器，一旦成形，容器将保持不变，无论内容如何，​​即使电子邮件已被创建为响应式。

总之——用李小龙的话来说——内容就像水：如果你把水放在杯子里，它就会变成杯子； 如果你把水放在瓶子里，它就会变成瓶子； 如果你把水放在茶壶里，它就变成了茶壶。

你不能指望杯子会变成瓶子，而茶壶永远不会是杯子。 因此，文本（或图像或按钮）必须适应包含它的结构，而不是相反。

第二个原因是更具操作性。 如果用于编写通信的所有参数都是先验已知的，那么不仅可以在起草阶段创建更有效的通信，而且还可以创建更平衡的通信。

让我们举一个更具体的例子：假设我们有一个包含两个并排产品的 DEM。 产品通常与：

• 一个图像
• 产品名称
• 产品描述
• 价格
• 指向产品页面的 CTA

现在，由于产品是并排的，零件必须平衡。

这意味着图像必须具有相同的高度，描述性文本必须具有相似的长度，并且两个 CTA 不能太相似。

忽略或不尊重这些基本原则可能会导致上图所示的情况。

这两个元素之间的对称性被打破了，因为左边的产品标题太长，覆盖了三行，而右边的太短，只占一行。 引入了不和谐，最终削弱了整个沟通。

在考虑移动世界时，遵守这些规则变得更加重要，其中所有不同的设备都有非常不同的分辨率：从 iPhone X 的 1125 x 2436 像素到三星 Galaxy S8 的 1440 x 2960 像素，通过Microsoft Lumia 1020 的 768 x 1280 像素。

当这种巨大的多样性与密集的电子邮件客户端丛林重叠时，这意味着我们无法完全控制 DEM 显示，因为没有确定的代码可以在每种情况下适应像素。 因此，如果您无法通过代码控制它，则必须尝试通过更改构成电子邮件的其他部分（例如文本的长度或图像的大小）来间接进行控制。

我们的建议：

• 定义模板的所有部分
• 在通信的不同部分之间保持一致
• 尊重你给自己制定的规则
• 规则可以被打破，但这必须在充分意识到的情况下完成
• 如果模板不能满足您的需求，您可以开始考虑定义一个新的

错误 4. 获取交互式电话号码和地址错误

有时，电子邮件发件人会添加他们的联系信息，尤其是在页脚中。 这通常包括地址和电话号码。

虽然电话号码和地址可以是桌面客户端电子邮件的标准信息，尽管它们很少使用，但这些元素在移动端尤其重要。

发生这种情况主要有两个原因：

• 您可以通过单击打开管理数据的应用程序（日历、电话、浏览器）
• 减少了显示空间，因此即使位于页脚中，每条信息也具有更大的可见性

因此，在开发通信时不要忘记这些细节也很重要，因为它们的行为在不同的设备上有所不同。

让我们花点时间考虑通过模拟临时创建的示例。 这两个示例均由 iPhone 6+ iOS 9 显示。

左图显示了用户收到的简报，文本直接输入，没有任何格式。

从技术角度来看，一切都是正确的，但我们必须考虑到代码是由移动设备上的电子邮件应用程序本身解释的事实。 它“读取”电子邮件的文本，当它识别出日期、地址或电话号码形式的文本时，它会自动将活动链接链接到相应的应用程序，即日历、地图或手机。

这一切都非常方便，因为只需单击一下，您就可以拨打电话、安排活动或打开地图来设置路线。 唯一可以为此感到难过的是美术和开发人员，他们不喜欢看到蓝色链接和下划线。 那么我们应该怎么做呢？ 我们应该如何进行？

您可以使用一个小的解决方法或技巧来使事情恢复正常。 让我们明确一点：尽管它们违反了格式良好的 HTML 的规则，但在浩瀚的电子邮件客户端中，变通方法是必不可少的。

如果开发人员的主要目标是使通信在尽可能多的客户端上可见，那么他们需要妥协并接受变通方法。

那么让我们看看代码是如何改变的。

对于电话，这很简单：由于锚标记可以通过在属性href 中使用tel来定义电话号码，因此我们添加电话号码时没有任何空格或分隔线。

但是，我们需要以不同的方式处理地址或日期。 对于这些，有必要定义一个类 (.address) 来施加锚标记，该标记将自动在客户端中插入颜色（颜色：#ffffff;）。 最重要的是，它应该删除下划线，这是每个链接的默认功能 (text-decoration:none;)。

请注意，地址类的两个属性都有!important ，无论属性如何，客户端都必须应用它。 没有它，就不能保证该变通办法能够完成它的工作。

我们的建议：

• 始终注意通信如何在手机上显示（即通过测试）
• 在可能的情况下，使用微修复使通信适合移动设备
• 不要假设对桌面有好处的东西也对移动设备有好处
• 了解您的受众：他们使用哪种技术？ 哪些设备？ 哪个媒体？
• 使用内部测试来试验您自己的通信，尤其是当电子邮件客户端应用程序有大量更新时

错误 5. 不清理废弃或空标签

继续尝试将通信的整体权重保持在最低限度的目标，我们需要注意现有代码中已清空其自然内容的部分。

让我们马上给出一个具体的例子：一个<font>标签，可能带有一系列内联样式，不包含任何文本。 显然，电子邮件端将无法读取任何内容，但<font>格式化标签继续存在并占据电子邮件中的物理空间。

另一个经典的例子是 <a> 没有链接对象的锚标签，比如： <a href=”http://www.mailup.com” style=”color:#00000;text-decoration:none”> </a>。

通常这些“错误”存在于那些经过多次返工或多次使用的代码中，因此不同的部分，例如图像、链接和文本，已被插入、修改或删除。 或者，这可能表明 WYSIWYG 编辑器使用不当。 事实上，如果使用不当或不谨慎，这些编辑器存在向代码添加代码的缺陷，因为每个预定义元素通常都有一部分从编辑器本身创建时就定义的代码。

每次插入所选元素时，程序都会不加批判地应用模型，因此，当您重写电子邮件的同一部分足够多次时，就会出现此问题。

我们的建议：

• 编写代码时，始终检查是否有废弃或空标签
• 如果您使用 WYSIWYG 编辑器并且可以访问代码，请执行检查以确保一切正常并且没有此类错误

错误 6. 使用未经验证的 HTML

谈论电子邮件代码的验证是一个棘手的话题。

“万维网上的大多数页面都是用计算机语言（如 HTML）编写的，这些语言允许网络作者构建文本、添加多媒体内容并指定结果应具有的外观或样式。

至于每种语言，它们都有自己的语法、词汇和句法，用这些计算机语言编写的每一份文档都应该遵循这些规则。 对于直到 XHTML 1.1 的所有版本，(X)HTML 语言都使用称为 DTD 的机器可读语法，这是一种从 SGML 继承的机制。

然而，正如自然语言中的文本可能包含拼写或语法错误一样，使用标记语言的文档可能（出于各种原因）不遵循这些规则。 验证文档是否真正遵循其使用的语言规则的过程称为验证，而用于此的工具是验证器。 成功通过此过程的文档称为valid 。

考虑到这些概念，我们可以将“标记验证”定义为根据它声称使用的语法（通常是 DTD）检查 Web 文档的过程”。

W3C 定义

W3C 通过提供代码验证工具来帮助我们作为代码的守护者和保证者，该工具的分析表明错误并建议纠正错误的方法。 借助此工具，可以识别和纠正较大的结构错误。

值得记住的是，电子邮件营销有两种情况：

• 一方面，HTML 是一种具有非常精确的规则和结构的标准化语言
• 另一方面，一系列不标准的变通方法，通常不受欢迎，但如果您想在电子邮件客户端上获得正确的可视化效果，这些变通方法效果很好

这两个方面就像一对老夫妻，激情早已烟消云散。 他们不知道为什么要住在一起，但他们被迫做出妥协。

那么为什么要谈论代码验证呢？ 是否有意义？ 有哪些妥协？

从更广泛的角度讨论代码验证是有道理的，而不是太深入细节。 因此，当涉及到结构、组成电子邮件的模块以及构成通信主干的表格时，拥有与 W3C 规定的标准一样干净且接近标准的代码是非常有意义的。尽可能。

然而，我们必须意识到现实，因此妥协在于创建一个坚固且功能性的结构，在其中添加变通方法作为一种微调，以将正确的可视化扩展到尽可能多的客户。

我们已经知道，变通方法只不过是规则的例外，或者不是完全正统的技术，源自通过经验积累的知识，但它们的存在仅有意义，因为它们允许正确可视化代码，无需任何分页。

我们的建议：

• 如果您对代码有疑问，验证可以作为一种快速有效的分析工具
• 代码验证可以成为快速识别代码清单中最大错误的好工具
• 经过验证的代码始终是后续发展和调整与变通方法的通信的绝佳起点，以使其尽可能通用
• 验证可以被视为代码的“服务”，尤其是在经常操作和返工的模型上
• 随着经验的积累，为各种客户建立一个小型的临时解决方案库，以节省解决问题的时间