CSS样式的动态过滤引入_基于浏览器特性的样式筛选-css教程-PHP中文网

@supports 规则比 JS 检测更轻量可靠，专用于声明级特性检测（需带值），支持 and/or/not 逻辑但 or 必须括号包裹；它不判断浏览器版本，也不保证运行时功能可用，fallback 必须依赖基础样式。

css样式的动态过滤引入_基于浏览器特性的样式筛选

怎么用 `supports()` 做浏览器特性检测并动态加样式

直接上结论：用 @supports 规则比 JS 检测更轻量、更可靠，尤其适合纯 CSS 场景下的渐进增强。它不是“能不能用某属性”，而是“当前浏览器是否真正支持该声明组合”。

常见错误是把 @supports 当成浏览器版本判断工具——比如写 @supports (display: grid) 却没考虑 IE11 虽不支持但也不报错，只是忽略整段规则；更隐蔽的是嵌套逻辑写错：@supports (not (display: grid)) and (display: flex) 实际会因括号优先级失效，变成 not ((display: grid) and (display: flex))，结果和预期相反。

只检测**声明（declaration）**，不是属性名本身，所以必须带值：@supports (color: oklch(50% 0.2 120)) ✅，@supports (color) ❌
支持 and/or/not，但 or 必须用括号包裹子条件，否则解析失败：@supports (display: grid) or (display: flex) 是非法语法，得写成 @supports ((display: grid) or (display: flex))
注意级联顺序：被 @supports 包裹的规则仍受 CSS 优先级约束，别指望它能绕过 specificity

`@supports` 和 JS 的 `CSS.supports()` 选哪个

二者底层用同一引擎判断，但行为有关键差异：CSS 规则里的 @supports 在样式表解析阶段就生效，而 JS 的 CSS.supports() 是运行时调用，可传入动态拼接的字符串，但也因此可能触发 layout thrashing。

典型误用场景：在 React 组件里反复调用 CSS.supports('display: grid') 判断渲染逻辑——其实只需执行一次，且完全可用 @supports 配合 class 切换替代。

静态样式适配 → 无条件选 @supports 规则，零 JS 开销
需要根据支持情况动态生成内联样式或修改 DOM 属性 → 才用 CSS.supports()，且建议缓存结果
CSS.supports() 的参数必须是完整声明字符串，不能只传属性名，也不能省略分号：CSS.supports('display', 'grid') ❌，CSS.supports('display: grid;') ✅（结尾分号可选，但建议带上）

哪些 CSS 特性不适合用 `@supports` 检测

不是所有“新东西”都能靠它兜底。比如 container-type: inline-size 这类依赖父容器显式声明的特性，@supports (container-type: inline-size) 会返回 true，但实际布局可能完全不生效——因为检测通过只代表语法被识别，不代表环境满足运行条件。

page-agent 浏览器控制（CDP）

使用 page-agent CLI（CDP）控制浏览器；CLI只能通过 GitHub Release 的 .tgz 安装，npm 官方包暂未发布。

下载

另一个坑是自定义属性（--my-color）：你无法用 @supports 检测变量是否存在或是否有值，它只认原生属性+值对。

涉及运行时上下文的特性（container、scroll-timeline、view-transition）→ 检测仅表示语法支持，不保证功能可用
自定义属性、@property 声明、font-palette 等需配合其他声明才能生效的特性 → 单独检测意义有限
部分 Safari 对 @supports selector(...) 支持不稳定，即使写了 @supports selector(:has(...))，也可能在旧版中静默失败