邮件中的深色模式支持分为三种情况,而大多数发件人所设计的 CSS 只覆盖其中一种。 一些客户端会按原样遵循 @media (prefers-color-scheme: dark)。另一些则会悄悄将其改写成永远无法匹配的语法,转而回退到自己的自动反色启发式规则。还有第三类客户端,几乎不理会较新的 color-scheme meta 标签。只为第一类客户端做设计,意味着覆盖不到收件箱的一半。
第一类:遵循媒体查询的客户端
根据 caniemail.com 的数据,@media (prefers-color-scheme: dark) 在 Gmail(所有平台)和 Apple Mail(macOS 12.4+ / iOS 13.0+)中获得完全支持。Outlook 在其大多数平台上紧随其后——Windows 版(2016+)、macOS 版(16.70+)、Outlook.com(2019-07+)和移动版(2020-01+)都能识别这条查询,不过 macOS 版 Outlook 和 Outlook.com 会在此基础上额外应用自己的深色模式数据属性。Samsung Email(Android 6.1+)也完全实现了该查询。综合来看,caniemail.com 测试面板给出的整体支持率为 41.86%——占主流客户端中真正的多数,但远非全部。
第二类:把查询改写成永远无法匹配的客户端
这一类客户端才是大多数发件人见过的、那些看起来出了问题的深色模式邮件的真正来源。Yahoo Mail、AOL 和 Fastmail 并不是直接忽略 prefers-color-scheme——而是把它改写成永远无法判定为真的无效语法(@media ( _filtered_a )),从而悄悄地让其中的每一条规则都失效。HEY 的做法类似,把这条查询改写成 @media (false)。在这两种情况下,客户端随后都会对原本的浅色模式设计,回退到自己的自动颜色反转启发式规则——而这正是导致标志发白褪色、文字对比度过低到无法阅读的原因,因为最终呈现的结果根本不是由发件人所写的内容驱动的,也没有人特意设计过这样的效果。
第三类:几乎无人采用的 color-scheme meta 标签
<meta name="color-scheme" content="light dark">(以及它的近亲 supported-color-schemes)的作用是告诉客户端一封邮件是特意为哪种(或哪几种)模式设计的,这样客户端就能完全跳过自动反色,而不必去猜。这是一种更为精准的修复方式——但根据 caniemail.com 的数据,其综合采用率仅为 4.88%,且真正有意义的支持仅限于较新版本的 Apple Mail(macOS 16+ / iOS 12.4+)和 Gmail 桌面网页版(2023-09+)。其余大多数客户端都直接忽略它。
这对设计意味着什么
没有单独一条 CSS 规则能同时覆盖上述三类客户端——这是上述划分的直接结果,而不是某一项技术本身的缺陷。可靠的方法是渐进增强,这也正是 Litmus 深色模式指南所得出的同一条原则:
- 先设计一封扎实、完全可读的浅色模式邮件。 这是每一个客户端最终都会回退到的基线,包括第二类中那些会自动反色的客户端。
- 在此之上叠加显式的
prefers-color-scheme覆盖规则,面向那约 42% 会真正应用它们的客户端——鉴于 meta 标签的采用率低得多,不要仅仅依赖它。 - 为标志和图片素材做好抗自动反色的加固:在第二类客户端中,一张衬在纯白背景上的半透明 PNG,反色后可能会变成一团深色叠深色、完全无法辨认的图像。在素材背后加一圈细边框或一块纯色背景,就能在反色后依然保持可读,而裸露的透明 PNG 做不到这一点。
- 切勿假定深色背景就意味着文字颜色也已针对深色模式做了适配——第二类客户端的自动反色可能只翻转背景,而不会按发件人预期的方式处理文字,因此在深色模式下,显式设置文字颜色反而变得更重要,而不是更不重要。
关于同样的逐客户端细分如何应用到 MailInApp 自身的工作室与降级引擎中,详见邮件客户端支持。