实现Responsive邮件的不同策略
本文由大漠根据Tina Ye的《Responsive HTML Emails: a Different Strategy》所译，整个译文带有我们自己的理解与思想，如果译得不好或不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：http://blog.fogcreek.com/responsive-html-emails-a-different-strategy/，以及作者相关信息
——作者：Tina Ye
——译者：大漠
电子邮件变得相当的重要，它在我们身边随时出现。所以我们重新在思考FogBugz邮件通知的制作，我们知道我们必须在随时随地都能阅读，这意味着移动端上要做很多的优化。
在这篇文章中有很丰富的资源。Campaign Monitor提供了一份响应式设计指南，文中一步一步教您如何设计与制作响应式邮件("EDM模板")。Ros Hodgekiss早在2011年8月份就在Smashing Magazine发表了一篇From Monitor To Mobile: Optimizing Email Newsletters With CSS。MailChimp 发表了移动电子邮件的最佳实践相关技巧。如果你不想阅读这么多文章，那你么可以花点时间阅读Litmus团队根据自己产品总结的一些响应式邮件制作的经验。
但是，有一个小问题，上面所有文章中，他们都提倡使用媒体查询功能。
媒体查询的难处
媒体查询在桌面浏览器上得到完美的支持，但至今仍然有很多电子邮件客户端无法识别媒体查询。其中最受欢迎的手机邮件客户端是Android和iPhone的Gmail，但仍然无法支持媒体查询。没有媒体查询检测设备和重新配置相应的布局，用户可能很难看清移动设备上的内容(因为文字太小了)，像这样：
一个移动端的设计策略，并不能解决一个最受欢迎的移动端电子邮件客户端，这不能称得上是一个很好的策略。所以我们在想...如果我们采用另一种不同的方法呢？
一个布局来控制一切
大多数的移动端电子邮件设计文章还是让你认为“不同的屏幕采用不同的布局”。例如，为桌面端电子邮件客户端设计一个两列布局，然后到移动端电子邮件客户端时调整为单列布局。这种策略在很大程度上是依赖于媒体查询检测设备宽度，然后由内容流，减少，或隐藏给i后个章节标题来采用适当的布局。当媒体查询支持仍然是如此参差不齐的情u情况下，你可以看到什么，这将是一个问题。
因此，不能依靠媒体查询来修改布局，我们认为，“为什么不设计一个布局，在所有屏幕的尺寸下看起来很不错呢？”
不可能吗？不，这是有可能的。
移动端第一
我的灵感来源于Luke Wroblewski的移动端第一的方法。在这里，首先要考虑到是极限制(移动端的极限性)，然后才开始设计。毕竟，将一只小猫装入一个大罐子中要比一个大的猫装进一个小罐子中来得轻松。不管怎么说，这是一个伟大的设计哲学，他让我们的最终设计达如何达到我们所有的差异。
我们开始在质问，什么布局能在移动端上很好的工作？回答我们的是“单列布局”。
单列布局，我的意思是，主要的内容流都是向下的，而不是两个向下和并列的。并列的内容在小屏幕下要重新回流。相比之下，一个直线向下的文档流意味着内容可以自适应水平方向的空间。瞧，在任何尺寸下的一列布局。
即变如此，有时候并列的内容为了适应小屏幕也不需要多次回流。有时，单列的内容能够在缩小的屏幕上运行的很完美。当然，我不提倡压缩文本内容至160px下，可以让他们保持并列显示。你可以看看Dan Denney的Code schools代码块。或者看看来自于Tinkering Monkey的排版漂亮的的促销邮件案例。
这些都是“桌面版本”的电子邮件，因为他们是单列的，你可以很容易的想像出他们在移动端缩小后的效果。上面的截图由Email Wizardry提供。
至于Fogbugz通知邮件的设计，我们的目标是快速和轻松的与案例沟通的状态。我们不需要一大堆的程序化的版式或引人注目的插图来做这个，这样反而会适得其反，让用户分散注意力。另一方面，我们确实需要传达大量的信息，所以我们依靠排版的层次，灵活的网和微妙的色彩来组织设计。在这里，我们可以先看看最后的设计：
因为多样性的信息存在要比一个严格的单列布局要复杂的多。但他的表现就像这样：可以很好的适应水平方向的缩放，不需要在一个小屏幕上重新堆放。 个布局适应多个屏幕。
希望现在我现在已经说服你从自己的设计中去除多个布局的枷锁，让我们的设计看上去也上了级别。
写代码
在移动端上，你使用的区域是有限的，所以理应尽可能多的使用屏幕上的可视区域。一个width:100%的流体布局能够生效。我们把他应用到最大容器元素的行内样式上，得到如下结果：
但在桌面上，这个相同的代码将创建另一个恶梦的开始：
这个很容易解决。让我们在两边增加一些空间。在主容器上添加一个简单的max-width（也是内联的）：
好多了。现大我们不违反任何排版规则。
这基本上就是它了。现在在移动端和桌面上有一个完美的响应，显示友好。不使用单独的媒体查询创建高品质的电子邮件布局。
等等，Outlook下怎么样？
该死的，麻烦又来了。事实证明，max-width属性并不能完全兼容所有电子邮件客户端。没有它，我们的邮件变得超宽和难搞。我们怎么样才能解决这个问题呢？
如果你可以自信的说，你的用户不会使用Lotus Notes，Outlook或者App Mail，那么你可以跳过这一节，继续往后阅读。如果你不能确认，那么请仔细阅读这部分内容，不会花你很长时间。
Lotus Notes8 和Outlook 2000~2003
因为Lotus Notes8和Outlook完全是桌面客户端，我们可以侥幸的迫使它们总是用一个固定的宽度来显示，用于优化桌面上的邮件显示效果。我们做的是通过给目标设置一个条件：Lotus Notes和老版本的Outlook使用的是IE渲染引擎，所以我们可以使用条件注释，先检查IE，给他一个固定的宽度来约束整个邮件的内容。
<!--[if IE]>
<table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
<tr>
<td>
<![endif]-->
[EMAIL BODY HERE]
<!--[if IE]>
</td>
</tr>
</table>
<![endif]-->
注意:约束的元素是table。这是因为，div在所有电子邮件客户端都不可靠。
Outlook 2007+
继续往下阅读，我们可以使用相同的策略用在Outlook 2007和更新的版本。唯一的区别是，Outlook 2007+采用的是Microsoft Office作为渲染引擎。不要问为什么，我们只需要添加gte mso 9的条件。这个条件表示的是“大于或等于Microsoft Office 9.0版本”，它涵盖了Office2000+版本。
<!--[if (gte mso 9)|(IE)]>
<table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
<tr>
<td>
<![endif]-->
[EMAIL BODY HERE]
<!--[if (gte mso 9)|(IE)]>
</td>
</tr>
</table>
<![endif]-->
Apple Mail
出人意外的是，经过我们的测试，Apple Mail也不尊重max-width！幸运的是，它确实支持媒体查询，所以我们可以添加一个媒体查询，让他回退。把需要的样式放置在<head>标签中的<style></style>内：
@media only screen and (min-device-width: 541px) {
.content {
width: 540px !important;
}
}
这只是说：“如果我的设备不是一个很小的手机，就会让邮件容器有一个固定宽度”。
完成了！所有的东西都在这个文件中。
最后，记得要测试测试再测试。我在Litmus，我的同事，和一小部分用户上进行测试。测试，直到你能测试没有什么问题，然后告诉世界你成功了。
现在你爽了吧，可以去做你想做的事情了。
应该注意到，这两个例子都使用了媒体查询来调整间距和调整图片的大小。如果移动设备上不支持媒体查询并不要紧，因为这些对于你来说也是相当不错的经验。这些布局可以使用媒体查询，但是他们并不一定要依赖于他们。
译者手语：整个翻译依照原文线路进行，并在翻译过程略加了个人对技术的理解。如果翻译有不对之处，还烦请同行朋友指点。谢谢！
如需转载，烦请注明出处：
英文原文：http://blog.fogcreek.com/responsive-html-emails-a-different-strategy/
中文译文：https://www.fedev.cn/css/responsive-html-emails-a-different-strategy.html
jordan retro 11 mens UK