CSS :has 不支持时怎么保留可用的降级样式

把 :has() 直接塞进唯一一套卡片样式，旧浏览器可能看不到你精心写的增强效果，甚至连同一条选择器规则都被忽略。更稳妥的做法是把页面拆成两层：先用普通类名、属性和结构写出可用的基础样式，再用 @supports selector(:has(*)) 叠加父级联动。这样不支持 :has 的浏览器仍能读懂状态，支持它的浏览器再获得更细致的卡片反馈。

最可靠的降级结构是“旧浏览器看基础状态，现代浏览器再看父级增强”：状态本身放在 HTML 中，`:has()` 只负责改善外层视觉，而不负责保存业务事实。

先让基础样式脱离 :has 也能成立

例如订单卡片需要展示“需要处理”状态。不要把重要信息只藏在父级背景色里，先让状态节点携带可读文本和稳定的类名；卡片边框、间距、标题颜色也先使用普通选择器完成。旧浏览器即使跳过后面的增强层，用户仍能看到状态。

需要处理
  
订单 A1024
  
付款信息需要人工确认

.order-card {
  /* 基础样式不依赖 :has，旧浏览器也能保持可读。 */
  border: 1px solid #d7dee8;
  border-radius: 12px;
  padding: 1rem;
  background: #fff;
}

.order-card__status {
  /* 文字和颜色同时表达状态，避免只靠背景色传递信息。 */
  color: #9b2c2c;
  font-weight: 700;
}

.order-card.is-error {
  /* 服务端或 JavaScript 能同步类名时，直接走这条兼容路径。 */
  border-color: #e1a3a3;
}

用特性查询把 :has 增强层单独隔离

MDN 将 @supports 定义为基于浏览器能力应用 CSS 的特性查询。对于选择器能力，可以使用 selector() 函数检测。把父级联动放进这个条件块后，旧浏览器不会把它误当成基础规则的一部分。

@supports selector(.order-card:has(.order-card__status)) {
  .order-card:has(> .order-card__status) {
    /* 现代浏览器只在一级状态节点存在时强化父级。 */
    box-shadow: 0 8px 22px rgb(155 44 44 / 18%);
    background: #fff8f8;
  }

  .order-card:has(> .order-card__status[data-level="high"]) {
    /* 高风险状态用更明显的外轮廓，但不替代文字状态。 */
    outline: 2px solid #c53030;
    outline-offset: 2px;
  }
}

这里的特性检测只回答“选择器语法是否可用”，不代表你的业务状态已经正确。状态仍应由 HTML 中的类名或属性表达。另一个细节是，> 把观察范围限定为卡片的直接子元素；如果状态被包在 .order-card__body 里，这条规则不会命中。是否应该命中，要由组件结构决定，不能靠不断放宽选择器来碰运气。

用 :where 和直接子代组合子控制增强规则

降级层常常还会和主题、组件库发生级联竞争。增强规则可以用 :where() 包住低优先级的结构条件，再把真正需要覆盖的属性写在组件类上。这样既能表达“卡片包含异常状态”，又不必人为堆叠很多类名权重。

@supports selector(:has(*)) {
  .order-card:has(> :where(.order-card__status[data-level="high"])) {
    /* :where() 的选择器权重为零，方便主题规则继续覆盖。 */
    border-color: #c53030;
  }

  .order-card:has(> .order-card__status[data-level="high"]) .order-card__action {
    /* 只有高风险卡片才显示提示动作。 */
    display: inline-flex;
  }
}

.order-card__action {
  /* 没有 :has 时不隐藏关键信息，动作可由服务端类名控制显示。 */
  display: none;
}

不要从 body:has(...) 或 *:has(...) 起步，也不要把无边界的深层后代查询放进高频变化区域。DOM 变化时，浏览器需要重新检查匹配关系；具体锚点和更短的内部路径更容易控制影响范围。对于菜单展开、输入校验这类频繁变化的状态，先评估组件子树大小，再决定是否需要 JavaScript 同步父级类名。

没有 :has 时，用状态同步保住关键动作

如果父级颜色只是增强效果，可以接受旧浏览器看不到阴影或轮廓；如果父级决定“提交按钮是否可用”，就不能把业务逻辑寄托在 :has() 上。服务端渲染时直接输出 is-error，客户端交互中用一个集中函数同步父级类名，都是更明确的兼容方案。

function syncOrderCard(card) {
  // 读取状态节点并同步兼容类名，保证旧浏览器也能得到基础反馈。
  const status = card.querySelector(':scope > .order-card__status');
  const isHigh = status?.dataset.level === 'high';
  card.classList.toggle('is-error', Boolean(status));
  card.classList.toggle('is-high-risk', isHigh);
}

这段脚本只是补足父级类名，不应该复制整套 CSS 状态。现代浏览器继续使用 :has() 做声明式增强，兼容路径只维护少数稳定类名，后续删除或调整增强效果时不会牵动业务状态。

发布前按这张清单决定是否采用

常见问题

只写 .card:has(...)，不写 @supports 可以吗？

在目标浏览器范围已经明确支持时可以，但降级页面更适合把它作为增强层隔离；这样基础样式不会和未知选择器绑定。

为什么用了 :has(> ...) 却没有触发？

检查状态节点是否真的是卡片的直接子元素，以及特性查询里的选择器是否拼写正确。中间多一层包装元素就不再满足 > 的边界。

:where() 是不是必须和 :has 一起用？

不是。:where() 的价值是让结构条件保持零权重，适合放在增强层控制级联；是否使用取决于主题覆盖和组件库的优先级设计。

参考资料在哪里？

CSS 选择器语义可参考 https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:has，特性查询语法可参考 https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@supports。