事情的起因是运营需要给用户推送各类活动邮件, 产品便把实现邮件模板的需求交由我来完成, 得, 有需求咱实现便是了. 一开始想的确实挺好, 不就是个静态页面嘛, 刷的一下就搞定了, 然后邮件发送出去各种兼容性问题, 所幸只是测试邮件, 不然就炸锅了. 果然事情没有想象中的简单, 网上查了一下发现 html 邮件模板的编写还是有点学问在的 (文末附有 HTML 邮件相关资源推荐)
编写前提
HTML 邮件模板的编写, 先排出以下前提条件
1. 邮件内容展示于第三方平台
2. 邮件的解析器比较老旧
以上两点前提是我们在编写 HTML 邮件时需要认识到的, 根据这两点前提加网上的总结, 我有以下注意点:
1. 采用 table 布局方式
根据前提条件 2, 在不知道邮件最终会在哪个第三方邮件平台上展示时, 确保布局不能乱的情况下只能用最保守的布局方式, 就是 table 布局. 这个布局方法是早期的网页比较流行的方式, 优点很明显, 兼容性无敌
2. 注意兼容性, 尽量有替代方案
还是前提条件 2, 尽量避免使用 CSS3 的语法, 很大可能性会失效, 那么要如何确定兼容性呢, 文末有附上鉴别工具. 在某些情况下, 在与设计和产品反馈说兼容性不太好的情况下仍要采用当前设计 (没错, 这种情况也有很多), 这时候就要尽量采用一些备用方案了. 比如以下所示:
- /* 失效情况下的补救方案 */
- background: #00A9BA;
- /* 渐变背景, 有可能会失效 */
- background: linear-gradient(90deg, #52D6CE 0%, #00A9BA 100%);
4. 行内样式优先
为什么说行内样式优先, 是因为第三方邮件平台展示邮件内容的时候, 有可能会去除邮件模板的 head,style 等标签, 如果样式是统一存放与 style 标签内的, 则模板也就乱了. 所以, 在编写邮件模板时, 尽量使用行内样式实现. 如果存在一些特殊的情况如需要处理响应式邮件时, 就不得不用到 style 标签来做 class 的处理, 这时候也得要有备用的兼容方案, 比如移动端样式优先显示, 通过媒体查询再显示 PC 端的内容. 当然了, 最好在设计前和设计师沟通一下 (大雾
5. 不要存在定位
通过兼容性的查询可知, position 属性基本不被主流邮件客户端支持, 这东西最好不用就是了. 具体的原因是什么没查到, 这里可以猜测的是, 如果开放 position, 那么有可能会将邮件客户端的内容给遮挡住, 这也是很尴尬的
6. No JavaScript!
这个自不必说了, 所有的邮件无法执行 JavaScript 代码, 为了安全性. 所以如果产品有要求对邮件进行一些脚本操作, 最好的办法就是跳转至自用的网站下再进行相应地操作.
7. 将元素放置于 body 中
将布局的内容及样式放置于 body 标签中, 是为了防止第三方客户端删除头部, 只保留 body 标签的情况出现. 这里要注意的一点是, 如果存在特殊情况下的 style 标签, 那么留在 body 中存在的概率会大一些.
End
存手工编写是最靠谱也是最麻烦的方法, 看实际情况而定, 邮件的实现必要时也需要和产品以及设计沟通, 切忌让设计天马行空的去搞, 不然麻烦的还是前端 (扯皮麻烦).
以下是一些邮件资源, 这里需要说明的是, 这一类的框架优点是比较省事, 不用写太多, 那缺点也很明显, 就是得学多一门几乎是新的语言
- MJML: https://mjml.io/
- emailframe http://emailframe.work/
- Foundation for Emails 2: https://foundation.zurb.com/e...
- responsive HTML email template: https://github.com/leemunroe/responsive-html-email-template
- campaignmonitor:https://www.campaignmonitor.com/a/
来源: http://www.jianshu.com/p/170372dbc868