一个有一定用户量的网站总是免不了会有消息模板，邮件模板之类的需求。我们一般通过这类功能向用户推送一些消息，及时给用户提供一些站内的最新情况。
邮件模板就是我们平时收到邮件的模板，当订好模板之后可以使用后端代码往模板里面动态填充内容。我们可以把邮件想象成一个页面，利用服务端动态渲染内容，然后把邮件发送给目标客户。另外可以把客户用来查收邮件的客户端想象成平时浏览网页所用的浏览器，只不过它是专门用来查收邮件的。
Email
这里似乎就有需要前端工程师的地方了，然而有前端的地方就有江湖，还有兼容性问题。
1. 样式内联
有一部分邮件客户端只支持内联样式，它们在展示我们邮件的时候会在邮件模板上添加各种奇奇怪怪的类名。比如网页版的Gmail就会把我们的邮件处理成下面这样
<div class="m_-1857700863831794185banner">
....
</div>
估计是想避免我们内嵌<style>标签影响网页端的表现吧。这样的话，无论你把样式写得多么模块化，类名定义的有多么规范都没有用，在以上情况下我们所编写的样式会全部失效。从兼容性方面考虑我们只能使用内联样式了。
然而内联样式无论是开发成本还是维护成本都相当高，为此我在项目中采取的方案是
先写出利于维护的CSS代码，然后通过线上编译器把他们编译成内联版本。
至于这个流程具体要怎么实施，每个人有每个人不同的喜好，以下是我的流程
- 先用Sass编写出模块化的样式代码。
- 用预编译工具编译成目标的CSS代码。
- 把生成的CSS代码放到邮件模板的
<style>标签中。 - 通过工具把邮件模板编译成我们需要的内联版本。
线上的内联样式编译工具我推荐MailChimp公司的CSS Inliner Tool。也可以使用HTML Email。
如果你也用Ruby语言可以使用Premailer这个Gem包进行编译。有了这样的工具库我们完全可以自己写脚本来让上面所说的流程自动化，至于具体要怎么实施，就看个人喜好了。
2. 用padding来取代margin
从某种程度上来说这种做法更利于我们的测试，提前发现问题。当我们在客户端看到内容之间有空隙的时候，往往忽视了这只是某些客户端的默认样式，实际上自己并没有设置任何样式，这也就导致了在不同的客户端之间产生了显示不一致的情况。而当我们规定自己只能使用padding而非margin的时候，当看到了不合理的空隙，你就会意识到可能自己忘记了重置客户端的默认样式了。
因此对于邮件模板的开发我的建议是
- 为所有元素都应用
margin: 0;这个属性来排除干扰。 - 采用
padding来增加内容之间的空隙。
我发现iCloud就是这样干的
iCloud
3. 定位陷阱
现在我们都进入到CSS3的时代了，定位的应用可以说越来越广了。我们甚至可以用定位加上转换效果来实现完美的垂直居中
xx-xx {
....
position: absolute;
top: 50%;
transform: translateY(-50%);
}
我也曾在邮件模板的开发中采用上面的技术，但不得不说，这是一个陷阱。网页版的Gmail能够轻易让你的定位属性失效，我曾经在调试过程中浪费了许多时间，请引以为鉴。
很多情况下，我们其实并不需要这么高端的布局技术，往往只是手里有锤子的时候看什么都像钉子。许多布局我们只需要简单使用float，padding这些属性就能够实现。
4. 莫谈响应式
看到邮件开发的各种限制，可能有人会想问响应式怎么办?。我不排除有些桌面端的邮件客户端是能够支持<style>标签来内嵌邮件样式，我们当然可以在这上面调整响应式布局。但个人感觉在邮件模板上做响应式的意义不大，还会徒添工作量。
对于邮件这类非应用性的 “前端页面”，我们着实没必要太过于注重移动端的表现。采用固定的宽度，可以使显示效果更加一致，也能够减轻开发成本。手机端查看的邮件时候只需要适当地缩放就可以了。只要设计合理，字体大小合适，我们就能够向客户传达我们想要传达的信息。
5. 尾声
上面简单总结了一些自己在邮件开发过程中的经验总结。个人觉得 作为邮件最重要的功能是传达信息(当然有个公司Logo也是很重要的)，其次是提供一些简单的链接让用户可以方便地跳转到一些指定地址，最后才是各种花哨的图片背景的设计。
而有些邮件除了内容动态之外其他的周边内容几乎不会有改动。对于这类邮件模板，我们或许可以考虑直接用一张设计好的背景图代替，而代码层面要做的只是动态渲染主体信息就可以了。如果周围的信息有所改变，我们维护的时候也只是需要替换一下相关的背景图，相比起维护一大堆CSS代码，这种方式或许可维护性更高，开发成本也更低。
网友评论