摘要

  • W3C 2011 年 9 月 1 日发布 CSS Conditional Rules 首份公开工作草案，用 @supports 根据浏览器是否支持某个 CSS 属性和值，决定一组样式能否启用。2012 年草案进一步写明用法。
  • 2013 年 4 月 4 日的候选建议规定 not、and、or 的组合；2022 年 1 月 13 日的候选建议快照明确，支持判断取决于处理器是否以可用程度接受该声明，而非把它当成解析错误丢弃。

浏览器早有一项礼貌：样式表里遇到不认识的声明，可以略过，继续处理后面的内容。一个边框颜色没认出来，页面大多还能站稳。换成一整套新布局，情况就没那么潇洒了。导航、列宽和内容顺序得相互配合；只搬来桌子，忘了搬门，办公室便会出现颇有实验精神的动线。

W3C 2011 年 9 月 1 日的首份公开工作草案给样式表增设了一道岗位面试。@supports 可以把一组规则放在某个属性和值的支持条件之后。浏览器能胜任，新布局便获得机会；另一个条件可以把备用布局交给不适合这个岗位的实现。早期草案还讨论 @document，后来 2013 年候选建议的重心是 @supports 这道能力问题。

面试题可以写得很具体，例如 @supports (display: flex)。它问的是一条声明，而不是浏览器自报的名声。2012 年 9 月 11 日的 W3C 工作草案继续整理条件语法：not 表示另一种答案，and 要求几项本领同时具备，or 接受不同的可行方案。设计者由此可以围绕真正需要的功能分组安排样式，而不必猜测某个版本的图标能做什么。

2013 年 4 月 4 日的 W3C 候选建议给出的示例很有现场感。一组柔性布局规则放在肯定条件下，另一组宽度规则放在 not 条件下。规范提醒，备用宽度若混进柔性布局，可能反过来妨碍它。这正是面试的价值：不是给页面别上一枚「支持新功能」胸针，而是让互相依赖的一整套规则共同进退。

浏览器回答「会」，标准上究竟算什么？2013 年文本把支持与接受声明联系起来：处理器理解属性和值，不会将其作为解析错误丢弃，并且对该值有可用程度的实现。2022 年 1 月 13 日的候选建议快照进一步明确，这个判断针对样式规则里的声明。旧办法靠浏览器跳过不认识的声明；新办法让需要协同工作的规则先得到一个共同的开关。

但面试题只问到了规定范围。W3C 举出高对比度偏好：浏览器可以支持 color 属性，读者的设置仍可改写最终看到的颜色。层叠规则、用户偏好、其他样式也参与成品。把「接受声明」当成「页面一定长得如设计稿」会让面试官高估自己的问题。应聘者说自己会做表格，不代表办公室的桌子已经摆对。

因此备用布局不能当成捡剩下的半套规则。它需要独立可读的顺序、合理的宽度和清楚的导航。新布局也得放进真实页面检验：标题是否被挤扁，表格是否冲出容器，阅读路径是否顺畅。@supports 帮作者根据能力分配任务；作品质量仍取决于任务书和实际安排。

2013 年，Bert Bos 在 W3C 的 WWW2013 CSS 讲解里把问题放到可运行的网页上。演示页先藏起六句状态文字，再用肯定、否定和 or 组合的 @supports 条件决定露出哪几句，其中一项测试 display: flex。读者打开页面就能看到浏览器给出的选择。这比猜设备版本直接得多；把一篇报道排得好看，还得作者另外动手。

四份 W3C 文件记录的是规范演进：2011 年首份公开草案、2012 年工作草案、2013 年候选建议、2022 年候选建议快照。它们提供了测试条件的含义，却不会告诉我们某一年所有浏览器的录取率。这场面试留下的长期价值是明确分工：浏览器回答能否接受某项声明，作者负责把肯定和否定两套页面都安排得像样。