使用 CSS :has() 根据内容为父元素设置样式

CSS 选择器从未涉足的方向

数十年来，CSS 选择器能够描述元素的上级和后代，也能关联到相邻的兄弟元素，但却无法根据元素内部的内容或其后跟随的内容来为其设置样式。使用 .card img 可以向下查找卡片中的图片；而使用 h2 + p 则可以从标题向前查找其后的段落。相反的情况则根本不可行：既无法根据嵌套的媒体内容来设置卡片的样式，也无法根据元素树中后续出现的段落来设置标题的样式。

这种不对称性并非 API 设计上的偶然现象。从历史上看，浏览器在处理文档时大多采用自上而下的单向遍历方式来应用样式。如果某条规则在判断其作用对象是否匹配之前必须先检查后续的兄弟元素或深层后代节点，就会打破这种单次遍历的处理模式。在大约二十五年的时间里，所有主流选择器引擎都遵循这一限制，而那些需要根据内容为容器添加样式的团队则通过其他方式绕过这一限制：使用 JavaScript 切换类名、添加额外的包装节点，或通过多个组件传递布尔属性来标记“该实例包含页脚”。

:has() 规则打破了这种 workaround，因为它允许规则自行查看 CSS 之前不允许访问的部分。一旦这扇门被打开，一个有趣的问题便是选择器引擎实际上可以被允许检查什么内容。

关系型样式也改变了设计系统记录不同变体的方式。无需要求作者在卡片包含媒体时总是记住某个修饰类，样式表可以直接从标记中已存在的结构中推导出该变体。这不仅方便，也是为何结构上的意外变化会导致视觉退化的原因。

:has() 实际检查的内容

伪类是一种以冒号开头的条件，附加在选择器上。常见的例子包括 :hover 和 :first-child：它们之所以能匹配，是因为元素的状态或结构位置，而非标签名、类或 id。:has() 也属于同一类别，但其参数是另一个选择器。它用于判断目标元素是否包含与该参数匹配的内容，或与之存在某种关联。

.card:has(img) {
  border: 2px solid royalblue;
}

这条规则的含义几乎可以直接理解：只有当在正在被评估的 :has() 关系中存在匹配的 img 元素时，才对 .card 应用此边框样式。:has() 之前的选择器用于指定接收这些样式的元素，而括号内的选择器仅用于定义条件。当该条件不成立时，:has() 将不会匹配到任何元素，因此这条规则也不会被应用。

有一个事实可以澄清大多数关于首次使用的困惑：声明会在 :has() 之前附加到主体上，而括号内的选择器仅作为谓词存在。常见的误解是“先选中图片，再为其卡片设置样式”。实际上其运行机制恰恰相反——浏览器会首先评估条件，然后再决定是否绘制外部主体。在讲解这一特性时，这种阅读顺序非常重要，因为那些只强调内部匹配条件的演示会让人把样式应用到错误的节点上。

“在其内部某处”这一表述仍然隐藏了重要细节：:has() 的搜索范围有多广？哪些关系会被考虑在内？

后代、子元素与兄弟元素：三种不同的搜索范围

传递给 :has() 的参数并非锁定为“任意后代节点”，而是一个完整的选择器。组合符——即用于定义选择器各部分之间关系的符号——会改变伪类所检查的内容。

/* descendant: image anywhere inside, at any depth */
.card:has(img) { }

/* direct child only: image must be an immediate child of .card */
.card:has(> img) { }
/* next sibling: heading immediately followed by a paragraph */
h2:has(+ p) { }
/* any later sibling: some paragraph follows, not necessarily right after */
h2:has(~ p) { }

这些选择器中的每一个都会检测 DOM 树中的不同部分。如果选择了错误的选择器，程序会静默失败：不会抛出任何异常。当开发者本意是使用 .card:has(> img)，却写成了 .card:has(img) 时，在简单的测试环境中可能看起来没问题，但在重新设计后增加了更多容器层、图片位于第三层嵌套结构中时，它却可能匹配到错误的卡片。

从根本上说，其功能词汇量相当有限：任意深度的后代检测、直系子节点限制，以及针对紧邻的下一个兄弟节点或后续任意兄弟节点的检测。悬停级联效果、表单验证样式、空状态检测等类似功能都是这四种检测方式的组合，除此之外并无更复杂的机制。

接下来的问题是，在实际生产代码库中，这些检测方式相较于两行代码的演示版本能带来什么价值。

一个能够对自身无法渲染的内容作出反应的框架

想象这样一个壳层应用：它负责页面布局，并将其他应用集成到其中——包括导航栏、产品列表组件以及通知面板。这些组件都是独立开发并部署的。这种运行时组合通常被称为微前端架构。其优势在于通知团队无需与壳层团队协调发布时间即可独立推送功能。

这种独立性也带来了壳层应用必须承担的成本。由于通知面板和壳层应用按不同时间表发布，壳层应用无法提前知道面板会显示什么内容。如果壳层应用希望在面板有内容可展示时立即更新主内容，以往的做法要么是在内容加载时触发共享事件，要么是使用双方都能读取的共享状态存储。但无论哪种方式都会让原本为降低耦合度而分开设计的组件之间产生关联。

/* shell/layout.css */
.main-content:has(~ .notification-panel:not(:empty)) {
  margin-right: 320px;
  transition: margin-right 0.2s ease;
}

<!-- shell/index.html -->
<div class="app-shell">
  <main class="main-content">...</main>
  <div class="notification-panel" id="notification-slot"></div>
</div>

// notification-panel/mount.js
import { renderAlert } from './alert.js';

export function mount(targetId, alertData) {
  const slot = document.getElementById(targetId);
  slot.appendChild(renderAlert(alertData));
}

在此使用:has()意味着只有当通知面板中包含实际内容时才会改变边距，而非在出现空的主节点时就立即变化。注意那些样式表中未包含的内容：没有事件总线，没有共享存储，双方也无需实现任何握手机制。即使两个团队从未看过对方的代码，只要它们操作的是同一个实时DOM，依然可以协调布局变化。

正是这种缺乏显式协调的特性，使得接下来的限制值得被明确指出。

范围的边界以及其隐含的假设

当布局逻辑涉及独立发布的组件片段时，有两个约束尤为重要。

技术隔离是首要原则。封装在 Shadow DOM 中的片段会形成一层不可见的结构树，外部样式无法查询该结构树，因此依赖内部为空状态的壳层选择器永远不会被触发。共享的轻量级 DOM 是实现这一目标的先决条件，而 Web Components 中默认的阴影封装机制实际上会抑制这种模式的使用。

第二个限制来自运行层面。那些以 .notification-panel 为依据的布局规则，假定该类名及包含关系始终稳定不变。一旦重新命名该类、将内容移至其他容器或在其他位置渲染，壳层就会停止响应，且不会引发类型错误或单元测试失败。此时进行调试就意味着需要重新发现由其他代码库所定义的隐性 CSS 规则。

与显式的事件处理或共享状态存储相比，这种情况并不一定更糟糕。耦合依然存在，只是体现为选择器文本中的依赖关系，而非导入的符号而已。

重新整合各部分

历史上的选择器引擎都是为正向遍历优化的，这也是这类关系型容器查询出现得较晚的原因。:has()终于让元素能够对后代、子节点以及后续的兄弟节点做出响应。这三种关系类型就足以解释外壳布局的变化——无需额外的伪语言。

同样的原理也解释了各种故障模式。尝试访问阴影树会直接失败；依赖外部类名则会导致无声失败。明智的团队会将关系型选择器视为与文档化的DOM规范相绑定的展示工具，而非替代微前端所有者之间明确约定的服务契约。