网页开发者都熟悉@supports这个CSS规则——它用来检测浏览器是否支持某个CSS特性，支持就应用样式，不支持就跳过。听起来很靠谱，对吧？但实际情况是，这个"检测器"本身就有bug，而且是个让人头疼的设计缺陷。

按照CSS规范，@supports只能写在最外层，或者嵌套在另一个条件规则（比如@media）里面。但现实中，浏览器对下面这种写法照单全收：

打开网易新闻 查看精彩图片 
.my-class {@supports (property: value) {}

这种嵌套写法理论上是无效的，但Chrome、Safari、Firefox全都认了。问题就出在这里——浏览器怎么处理这种"非法"嵌套，直接决定了你的代码会不会出岔子。

来看个具体例子。假设你想给列表项的标记符加点花样：

li::marker {@supports (content: " - ") {content: " - ";color: red;}

这段代码想表达的是：如果浏览器支持content: " - "，就把列表标记改成红色的" - "。Chrome和Firefox确实这么渲染了。但Safari呢？它显示的是一个红色圆点。

诡异之处在于，Safari明明不支持::marker伪元素里的content属性，@supports的检测结果却返回了"支持"。开发者看到的是嵌套结构，浏览器执行的却是另一套逻辑——它把@supports提到了最外层，检测的是"这个声明语法上是否有效"，而不是"在这个具体场景下是否真的能用"。

说白了，@supports检查的是语法合法性，不是上下文兼容性。它不会问"这个属性在这个选择器里能不能用"，只会问"这个属性我认不认识"。

怎么解决？作者提了三个可能的方案。第一个是扩展and运算符，让开发者能组合检测：

@supports selector(::marker) and (content: " - ")

第二个是引入新运算符（比如xand），强制要求两个条件在特定上下文中同时成立。第三个更直接——新增一个rule()函数，直接检测整条规则的有效性：

@supports rule(::marker { content: " - " })

这些方案的核心思路都一样：让@supports能判断"这条声明在这个地方是否真的有效"，而不是只判断"这条声明我认不认识"。

当然，还有个简单粗暴的备选方案：浏览器直接禁止嵌套@supports，检测到就报错。但这会打破大量现有代码，代价太高。

作者也提到了现有的变通方案——容器查询（container queries）和样式查询（style queries）。不过这两者目前支持度有限，而且只能检测自定义属性，没法直接检测普通CSS声明。能用，但不够彻底。

这个案例暴露了一个深层问题：CSS的"渐进增强"工具本身就不够渐进。开发者以为自己在写防御性代码，实际上写的可能是"在部分浏览器里静默失效"的代码。更麻烦的是，这种失效不会抛错，不会警告，只是样式不对——等你发现的时候，可能已经上线很久了。

对于天天跟浏览器兼容性打交道的前端工程师来说，这不算新闻。但每次遇到这种"规范说一套、浏览器做一套、检测工具还帮倒忙"的情况，还是会让人想叹气。毕竟，连"检测支持不支持"这个功能都不完全支持，这本身就很CSS。