苹果发邮件_苹果发邮件显示用户名或密码不正确

作者 | s0.rumi

译者 | 核子可乐

策划 | 丁晓昀

首先，如果大家点进来的原因是厌烦了开发邮件系统，请允许我先对各位的悲惨遭遇表达最诚挚的慰问。

说说结论，我认为邮件系统的开发可以说是能在笔记本电脑上完成的、最恶心的工作，没有之一。我们做的一切似乎都没有意义，只能像疯子一样反复测试一切，那种感觉跟清理浴室地板上莫名其妙的顽固污渍倒有几分相似。

总之，希望文章接下来的内容能帮大家厘清整个混乱的局面，提供一点有用的建议，特别是让您在绝望中找到一丝活下去的勇气。

邮件开发是干啥的？

理论上讲，邮件系统的开发其实跟网站开发应该比较相似。电子邮件在本质上只是个 HTML 文档，跟网页一样，只不过是在邮件客户端、面非网络浏览器中呈现视觉效果。但除此之外，二者都能渲染，也就是把 HTML 代码转换成文本、图形和图像——即内容的可视化。

其实在 2005 年那会，网站和邮件系统的开发其实非常相似。浏览器和邮件客户端会以几乎相同的方式呈现 HTML，而且功能也相差不大。但是，尽管 Web 标准不断发展且持续入驻网络浏览器，但邮件客户端这头却似乎陷入了时停——至今无甚变化。

如今，我们在开发网站时可以支持各种酷炫且高效的功能，比如网格、Flexbox、夜晚模式、过渡，而且所有主要浏览器都能兼容。但另一方面，这些功能在邮件客户端中则分以下三种情况：

完全不受支持；

无法按预期工作；

在某些邮件客户端中无法兼容。

所以，如果大家希望一定比例的用户（至少得有 95% 吧）能按预期查看邮件内容，那就只能坚持使用最基本的 HTML 和 CSS 功能。而且即使这样，成功率也不是 100%……

而且更离奇的是，如今 Web 开发中最糟糕的实践竟然仍是邮件开发中的最佳实践。下面，就让我们一探究竟。

首先，如果大家点进来的原因是厌烦了开发邮件系统，请允许我先对各位的悲惨遭遇表达最诚挚的慰问。

说说结论，我认为邮件系统的开发可以说是能在笔记本电脑上完成的、最恶心的工作，没有之一。我们做的一切似乎都没有意义，只能像疯子一样反复测试一切，那种感觉跟清理浴室地板上莫名其妙的顽固污渍倒有几分相似。

总之，希望文章接下来的内容能帮大家厘清整个混乱的局面，提供一点有用的建议，特别是让您在绝望中找到一丝活下去的勇气。

为什么要用 元素?

邮件开发最让人头痛，当数其中大量使用到 table 元素，以及永无止境的和字符串。但是，为什么会这样？

根据相关文献的解释，微软 Outlook 使用着与 Word 相同的渲染引擎。也就是说，在 Outlook 中打开电子邮件基本上相当于在 Word 中打开文档，所以我们得先摆正思路——手头开发的并不是电子邮件，而是 Word 文档。

有朋友可能会想，“不会吧，Word 里可没有多少布局和样式工具……”说得没错！但它有 table，而且只有 table。所以任何想要正确实现可视化的内容都必须是 table。没有其他办法了，请大家收下这份表格大礼。

为了证明这一点，以下是苹果发送的现代电子邮件被粘贴进微软 Word 2013 后的样子：

微软 Word 2013 中打开的苹果发票邮件

神奇吧，这格式多么规整。而之所以能这么规整，是因为邮件的 HTML 中包含 75 个和 122 个。看看 HTML 格式，就知道内容有多乱了。

为什么要使用内联样式？

跟常规 HTML 文档一样，电子邮件也可以具有 CSS 样式。如果各位朋友足够理智，肯定会想到把它们放在文档的标记当中。根据“如何开发邮件……”支持页面中的<>和<>部分的说明，这种处理方式能让样式得到良好渲染。

我们可以选择“正确的方式”，也就是发送邮件、打开邮件，然后发现它的呈现效果跟预期一致。但问题是用户不只会接收邮件，还会撰写自己的邮件，甚至进一步再做转发。

那在转发电子邮件时，具体会发生什么？根据 Stack Overflow 上的回答，简单来讲，中的所有内容都会被删除。就是说我们向其中添加的任何新式，都会被 Gmail 无情抛弃。

唯一不会被删除的样式就只有内联样式。因此，如果希望电子邮件在转发之后仍然正常显示，那就只能使用内联样式。

以下是我转发的苹果通知邮件：

在 Gmail 中渲染得到的转发邮件

看着没什么毛病，对吧？那是因为其中用到了 40 个内联样式属性。不信？大家可以看看这封邮件的 HTML 代码证明我没说谎：https://dodov.dev/blog/why-does-email-development-have-to-suck/email-inline-styles.html

下面我们删掉内联样式，看看更新之后的 HTML。在浏览器端，二者的显示效果几乎相同，因为内联样式所提供的样式会被复制到当中作为后备。但因为转发邮件时这些样式会被删除，所以我们的样式就彻底消失了：

Gmail 中渲染的、不带内联样式的转发邮件

可以看到，标题、页脚、间距全都是一团糟……这显然不对劲，但至少还有个合乎逻辑的理由——保障安全。电子邮件客户端在渲染 HTML 之前，会对其进行预处理以保证安全，样式也是这样被丢掉的。

如果大家希望自己的邮件在转发时看着能有点章法，那就必须拿起内联样式的“颜料瓶”冲着 CSS 之墙拼命喷洒。

颜色反转

在开发网站的时候，我们会用 Prefers-Scheme 来检测用户是否在 DAMB 模式下查看，并相应更改当前页面的调色板。您猜怎么着？大多数电子邮件客户端还不支持这项功能。时间已经过去了 20 年，Apple Mail 等少数客户端倒是支持，但 Gmail 却采用了另一种不同的方法……

在谷歌看来，一切问题说到底都是概率论问题。只要在数学上具备可行性，那就可以完全不管少数情况下的怪异效果，这就免去了重新设计调色板和其他颜色的麻烦。

所以在夜晚模式下，Gmail 会简单将邮件中的所有颜色反转——包括背景、边框和文本颜色，如下图所示：

iOS 版本的 Gmail 客户端，会在夜晚模式时直接将颜色反转

可悲的是，这事我们防不胜防、几乎没办法做预先控制。唯一的办法就是尽量拣选那些在反转之后效果仍然不错的配色，保证图像在常规和反转配色时都有过得去的观感……这事不容易，大家多留点时间吧。

全宽内容

在移动设备上，我们可能需要让内容从一端显示到另一端，正常的网站也都是这么显示的。大多数移动邮件客户端也都支持这种方案，除了……Gmail。

Gmail 在每封邮件的侧面，都放置了一块莫名其妙的 16 像素空白。

Apple Mail 和 Gmail 的侧边留白比较

我们没法去掉这块留白。查看边距？已经是 0 了。填充？是 0。而且!important 已经全部应用过了。反正就是解决不了，你既检测不到它、也没法做进一步处理。忍着吧，强迫症们！

自定义字体

对组织来说，品牌中最重要的组成部分应该就是字体了吧，所以我们当然想在邮件中也继续使用自己的独特字体……可以吗？行啊，除了 Gmail。

大多数电子邮件客户端都不支持 font-face 字体，但这却是 Gmail 那边使用率最高的字体。

Stack Overflow 发帖有云，这时候只能使用设备操作系统提供的本地字体。总之，希望各位的品牌多跟 Arial 和 Times New Roman 合作！