选择响应式电子邮件框架：MJML 与 Foundation For Emails

实现响应式电子邮件设计可能有点拖沓。构建响应式电子邮件并非易事，就像乘坐时光机回到 2001 年，当时我们都在使用 Dreamweaver 和 Fireworks 在表格中编写网站布局。

但是，希望还在！我们拥有可用的工具，可以使构建电子邮件变得更加容易，更像是在编写现代网站。让我们看一下几个旨在简化我们工作流程的框架。

首先，情况

您必须与许多旧的电子邮件客户端兼容，其中许多甚至不支持最基本 Web 标准（浮动，有人吗？）。您还必须处理各种 Web 邮件客户端，它们出于安全或技术原因，对如何显示您宝贵的电子邮件做出了自己的意见。

此外，现在电子邮件是从不同的设备读取的，具有非常不同的视窗和要求。

最佳解决方案，就像经常发生的那样，是保持简单，坚持使用基本的一列设计，仅在菜单或已知宽度的简单界面元素中使用多列。毕竟，您只需使用一列即可制作出出色、有效的设计。

但是，习惯了“正常”基于浏览器的 Web 的最终用户和客户可能会将其电子邮件查看体验保持与他们在图形和响应能力方面查看网页相同的标准。因此，人们期待复杂的设计：多列，移动设备与台式机上的不同行为，大量图像等，所有这些都必须在所有电子邮件客户端中一致且像素完美地实现。哪些选项可以实现这一切？

选项 1：从头开始构建

您可以选择的一个选项是手动编写每个电子邮件，保持简单，并在编写时进行测试。仅当满足以下条件时，此选项才可行

1. 您需要实现非常简单的设计。
2. 您可以直接控制设计，因此，如果您无法找到要执行的操作的一致解决方案，最终可以简化设计。
3. 您可以接受某些旧客户端上的某种程度的降级：例如，如果您不介意您的电子邮件在旧版 Outlook 客户端中看起来不完全相同（甚至很糟糕）。
4. 您有大量的时间。

显然，您需要对设计进行大量测试。Campaign Monitor 有一个很棒的 CSS 指南，您可以在构建过程中参考它，并且有点像 Can I Use，但适用于电子邮件。之后，我建议使用 Litmus 或 Email on Acid 等自动化测试套件。两者都为您提供完整的测试套件，并提供电子邮件在各种电子邮件客户端中的外观预览。不过，请预期出现一些意外情况，因为通常情况下，即使在同一电子邮件客户端上查看，但如果在不同的浏览器或不同的操作系统上查看，相同的设计也不会看起来正确。字体将以不同的方式呈现，边距将改变，等等。

选项 2：使用样板模板

另一个选项是使用各种可用的样板，例如 Sean Powelll 的 您可以在此处找到的样板。样板已解决不同电子邮件客户端和平台的许多问题。如果满足以下条件，此操作是合理的

1. 您独自工作，或在一个小型团队中工作。
2. 您拥有丰富的经验，因此您已经了解电子邮件格式的大多数问题，因为您以前遇到过它们。
3. 您已经设置了自己的工具来管理组件（用于共享部分设计元素的不同通讯）、内联样式（是的，如果您向国际受众发送电子邮件，则应继续内联您的样式），并且已经拥有某种开发工具包（无论是 Gulp、Grunt 还是类似工具），这些工具包将为您自动执行所有这些操作。
4. 您喜欢控制自己编写的代码中的所有内容，并且不喜欢依赖外部工具。
5. 您更喜欢解决自己的错误，而不是解决使用工具可能导致的错误。

选项 3：使用框架

但是，如果以下任何要点对您适用

1. 您必须使用共享组件制作大量电子邮件模板。
2. 这项工作必须由一个开发人员团队执行，这些开发人员可能会发生变化，或者其电子邮件实现能力和经验水平可能会有所不同。
3. 您对原始设计几乎没有或没有控制权。

…那么您很可能从使用框架中获益匪浅。

目前，MJML 和 Foundation for Emails 是两个最有趣且最流行的框架。使用这两个框架的最大优势在于，它们已经为您解决了大多数电子邮件客户端的怪癖。它们还为您提供了一个可以遵循的既定工作流程，无论您是独自一人还是作为团队工作。它们还可以很好地处理响应式设计，尽管方式不同。

让我们概述一下这两个框架，并比较每个框架最适合的用例，然后再得出一些结论。

MJML

MJML 是一个由 Mailjet（一家专门从事电子邮件营销工具的公司）内部创建的项目。然后它成为开源项目。它使用自己的自定义 HTML 类模板语言，使用自己的标签。例如

<mj-text>Your text here</mj-text>

当您编译最终代码时，MJML 会将其标签转换为 HTML，以用于从表格到它们为您创建的自定义组件的所有内容，所有这些都使用其内部引擎。它消除了创建复杂标记的繁重工作，并且所有这些都经过测试。

MJML 有一套 标准组件。它们包括部分、列、组、按钮、图像、社交链接（非常易于创建）、表格、手风琴等。它们甚至包括一个预先设计的轮播，应该可以在大多数客户端中使用。所有这些组件都很好地转换为响应式电子邮件，除了“发票”组件，我在测试中无法使其正常工作。所有这些组件都有您可以传递给代码的参数，以自定义其外观。

例如，社交链接组件允许您垂直和水平堆叠图标，以及为相关图标选择背景颜色。实际上，您可以在其中使用 更多参数，所有这些参数的目的是为了实现更大的灵活性。甚至徽标图像文件也已包含在包中，这是一个很大的优势。

这是社交链接组件的简单配置的预览

您还可以 创建自己的自定义组件，或使用社区创建的组件。但是，目前只有一个社区组件可用。

MJML 会自动处理响应能力，这意味着组件将从多列（同一行中的更多项目）切换到单列（项目一个接一个放置，而不是并排放置），而无需开发人员进行任何主动干预。这是一个非常灵活的解决方案，并且在大多数情况下都能正常工作，但它让开发人员对模板中发生的具体情况的控制力降低了一些。如 文档中所述，请记住

出于美观目的，MJML 目前每个部分最多支持 4 列。

这很可能不仅仅是审美偏好，而且是为了限制过多列可能带来的弊端。我认为，列越多，输出结果就越不可预测。

如何使用 MJML

MJML 可以用作命令行工具，您可以使用 npm 安装它，并在本地输出您的文件，使用以下命令

$ mjml -r index.mjml -o index.html

这可以通过 Gulp 等方式集成到您的构建流程中，并通过使用 watch 命令集成到您的开发工作中，该命令将在您保存文件时更新您的预览

$ mjml --watch index.mjml -o index.html

MJML 有 Atom 和 Sublime Text 的插件。在 Atom 中，它甚至提供布局的实时预览，可以在每次保存时重新生成。我个人还没有尝试过，但它看起来非常有趣。

MJML 也有自己的简单 桌面应用程序，它是免费的。您可以设置代码和组件，让它为您构建设计，并获得结果的实时预览，包括移动端和桌面端。我发现它在 Ubuntu 上运行得很好，但我发现的唯一缺点是，您永远不应该、永远、永远在应用程序打开时用其他编辑器打开您的文件，因为应用程序会崩溃，文件内容会丢失。

以下是一些正在工作的预览截图

该应用程序还可以与免费的 Mailjet 帐户集成，允许您立即向自己发送测试电子邮件。如果您有可直接使用的邮件客户端，这对于快速检查有问题的客户端非常方便。（我建议您取出存储室里那台旧的 Windows 机器来检查 Outlook，并尽可能频繁地这样做。）但是，我仍然建议使用 Litmus 或 Email on Acid 在部署电子邮件之前进行跨客户端测试，因为您永远不会太谨慎，电子邮件标准会像浏览器一样发生变化。

总的来说，我发现 MJML 很容易使用。但是，当我尝试制作一个与客户要求的设计完全一致的像素完美模板时，我在处理一些图像的自定义边距时遇到了一些困难。并非所有可用的组件参数都按文档中的描述预期工作。特别是，我在自定义图像边距和桌面和移动设备之间的填充方面遇到了一些问题。

优势

• 预构建组件
• 与 Mailjet 集成
• 易于使用，并提供工作的即时预览（在 Atom 和桌面应用程序上）

劣势

• 如果您需要进行像素完美的设计，那么它比 Foundation for Emails 的可靠性稍差
• 某些组件的参数不能按预期工作
• 桌面应用程序不完全稳定
• 没有提供用于内容的结构化文件夹集（请参阅下面的 Foundation）

Foundation for Emails

Foundation for Emails（以前称为 Ink，在此插入一句关于 Prince 的必备引用）是 Zurb 的一个框架，Zurb 同样带来了响应式前端框架，Foundation for Sites。

当您下载 入门套件 时，您将获得一个完整的开发环境，包括用于运行项目的 Node.js 命令。它将设置一个 Node 例程，甚至打开您的浏览器，让您立即预览您的工作。

您需要使用的文件已经组织到文件夹和子文件夹中，并清楚地表明在哪里放置您的内容。例如，它有专门用于部分、模板和图像的目录。我发现此功能非常重要，因为当您在一个团队中工作时，很容易最终使用不同的文件夹，这会导致很多时间浪费在寻找不在您预期位置的内容上。强制执行约定不是限制；当您在团队中工作时，它是不可或缺的。

Foundation for Emails 带有一个样板模板，它是代码的起点。它完全注释，因此您知道如何使用您的代码对其进行扩展。它带有 SASS/SCSS 支持，这对于复杂的项目非常有用。它还带有自己的内联工具，因此您不必担心将所有 CSS（或 SASS/SCSS）转换为内联样式。

该框架背后有一个名为 Inky 的模板引擎。并且，就像 MJML 一样，它有自定义标签，这些标签会在编译时自动转换为 HTML。有一些标签，比如 <container>、<row>、<column>，将用于构建您的网格。网格基于一个 12 列系统，允许您非常精确地细分布局。为什么是 12？因为它可以被 2、3、4 和 6 整除，使得创建 2 列、3 列、4 列或 6 列布局非常容易。

Foundation for Emails 使用 Panini 来编译代码。Panini 是一个自定义库，它使用布局编译 HTML 页面。它支持 Handlebars 语法，并且有一些辅助程序可以用来根据组件的使用位置来定制组件的行为。如果您需要，您也可以创建自己的辅助程序，并使用自定义数据设置每个模板的自定义变量。如果您有多个模板共享相同的组件，这将非常有用。

有几个 可供下载的预构建电子邮件模板，涵盖了电子邮件的许多标准用例，如时事通讯和公告。还有一些预构建组件（有自己的自定义标签），包括按钮、菜单和提醒（我必须承认，我不明白它们在电子邮件中的作用，但没关系）。

Foundation for Emails 与 MJML 的主要区别在于，Foundation for Emails 默认使用桌面视图，然后缩放到较小的屏幕。根据文档，这是因为许多桌面客户端不支持媒体查询，并且默认使用大屏幕布局使其在电子邮件客户端中更加兼容。也就是说，它只管理一个断点。您创建桌面版本和移动版本，移动版本在一定像素数下切换，可以配置。

您可以使用方便的预定义类来决定某些组件是否只在大型或小型屏幕上可见，例如 .hide-for-large 和 .show-for-large（尽管 .hide-for-large 可能不受所有客户端支持）。您还可以使用特定类来决定一列占用多少空间。例如，.large-6 和 .small-12 类在一个 div 上将创建一个列，该列在桌面端占用屏幕的一半，在移动端占用整个屏幕宽度。这使得可以获得非常具体和可预测的布局结果。

在我看来，Foundation for Emails 比 MJML 使用起来稍微笨拙，但它确实允许对布局进行更严格的控制。这使得它成为需要复制像素完美设计、在移动和桌面布局之间具有非常具体差异的项目的理想选择。

优势

• 对最终结果进行更精确的控制
• 预构建模板
• Sass 支持
• 优秀的文档

劣势

• 项目文件大小很大，占用大量磁盘空间
• 与 MJML 在组件上的预定义参数相比，使用起来略微不太直观
• 可用于自定义布局的组件较少

结论

制作电子邮件模板，即使比前端开发更简单，也不是一门精确的科学。它需要大量的尝试和错误，以及大量的测试。无论您使用什么工具，如果您需要支持旧的客户端，那么您需要对布局进行彻底的测试 - 特别是如果它们有哪怕是最小程度的复杂性。例如，如果您有需要放在图像旁边的文本，我建议使用不同长度的内容进行测试，并查看所有客户端的情况。如果您有需要与图像重叠的文本，那可能是一场噩梦。

布局越复杂，您对布局的控制权越小，那么使用框架而不是手动编码您自己的电子邮件就越有用，尤其是如果设计是由第三方提供的，并且必须按原样实现。

我不会说一个框架比另一个框架更好，这不是这篇文章的重点。相反，我建议针对不同的用例使用 MJML 和 Foundation for Emails

• 对于需要快速完成并且设计灵活的项目，可以使用 MJML。
• 对于需要对布局进行更严格的控制以及设计非常具体的项目，可以使用 Foundation for Emails。

资源和链接

• MJML 网站
• Foundation for Emails 网站
• Litmus 电子邮件测试
• Email on Acid 测试
• Litmus 论坛上的一个有趣的对话，在某种程度上，它是这篇文章的起点。
• James Luterek 的另一篇文章，比较了这些框架