每个主流邮件客户端在渲染邮件之前都会剥离 <script> 标签——没有例外,也没有针对发件人的选择退出机制。 所以,当一封邮件带有一个能正常运作的轮播图、一个可以展开的手风琴,或是一个能为答案打分的测验时,这些都不是靠 JavaScript 实现的。真正起作用的是一个隐藏的复选框、一个 CSS 选择器,以及邮件开发社区称之为"状态机"的一种技术。
问题所在:邮件客户端会剥离 <script>
Web 互动几乎总是假定 JavaScript 可用。邮件完全无法做出这种假设——Gmail、Apple Mail、Outlook 以及其他每一个主流客户端,都会在邮件到达时将 <script> 标签作为基线安全措施移除,无论发件人在邮件中包含了什么、邮件又是如何签名的。任何在邮件里表现得像应用程序的东西,都必须完全用 HTML 和 CSS 来表达,因为到渲染的那一刻,真正能留存下来的就只有这些了。
技术原理:隐藏输入框与兄弟选择器
其核心机制是应用在真实 HTML 表单控件上的 CSS :checked 伪类:
- 一个隐藏的
<input type="radio">或<input type="checkbox">用来跟踪一项状态——哪张轮播图幻灯片处于激活状态、某个手风琴面板是否展开、选中了哪个测验答案。 - 一个可见的
<label for="...">包裹住收件人应当能点击的任何元素——一个"下一个"箭头、一个手风琴标题、一个投票选项——并在点击时切换该输入框的选中状态,完全不涉及脚本;这是浏览器原生的<label>/<input>行为。 - 一个 CSS 兄弟选择器(
:checked ~ .panel、:checked + .content)会根据该输入框的选中状态为其他元素设置样式——显示一张幻灯片、展开一个面板、揭示一条"你选择了 B"的提示。
把足够多这样的组合叠加起来——每种状态对应一个输入框,每一次由此产生的样式变化对应一条选择器规则——最终呈现出的就是一个真正具有状态的界面,而它完全由标记构建而成,客户端的 <script> 剥离流程从不会触及这些标记,因为根本没有脚本可剥离。
真实支持情况:逐客户端分解
| 支持级别 | 客户端 | | --- | --- | | 完全支持 | Gmail(所有平台,自 2020 年 3 月起)、Apple Mail(macOS 12.4+ / iOS 13.3+)、Yahoo Mail、ProtonMail | | 部分支持 | Outlook.com、新版 Outlook 和移动版 Outlook("仅在类型选择器上受支持");Samsung Email(Android 7.0+) | | 不支持 | 经典版 Windows Outlook(2007–2019);Orange 与 SFR 网页邮箱(直接剥离输入元素) |
这与2026 年邮件客户端渲染现状报告中动态 CSS 整体约 91%+ 的真实触达率,是实质上不同的两个数字——caniemail 的数字对每个客户端一视同仁地计数,不论实际有多少收件人在使用它,而触达率则是按真实的追踪打开量占比来加权的。经典版 Windows Outlook 完全不支持这项技术,但它在市场份额中所占的比例本就在不断缩小,而这一份额早已被 Apple Mail 一家远远超过——这正是为什么应当以实际使用量而非客户端数量来加权,才是真正应该驱动设计决策的数字。
在不支持 :checked 的地方会发生什么
在完全不支持 :checked 的客户端中,隐藏的输入框和额外标记只会渲染为不起作用的元素——不会报错,不会导致布局破损,只是没有互动效果。该模块会回退到其默认标记顺序所呈现的内容:轮播图的第一张幻灯片、收起状态的手风琴、一份普通的静态测验选项列表。刻意设计好这种回退,而不是任由不受支持的客户端展示一些半破损的内容,正是降级引擎实际的职责所在——这项技术所处的完整三层模型,详见降级机制如何工作。