Interop 2026 媒体伪类怎么用：播放状态样式与兼容边界

如果播放器卡片只能靠 JavaScript 反复切换 class，播放、缓冲和拖动很容易出现短暂的错误提示。Interop 2026 把媒体伪类列入互操作重点，提供了一个更清晰的分工：媒体元素自身负责状态，CSS 负责表达状态。本文只讨论界面样式和兼容边界，不替代播放器的播放控制逻辑。

结论：可以先用 :playing、:paused、:buffering、:stalled 和 :muted 为 或 提供视觉反馈；基础文本和按钮仍要默认可用，再用 @supports selector(video:playing) 渐进增强。

先分清媒体伪类解决的是哪一层状态

媒体伪类匹配的是可播放元素的当前状态，而不是播放器业务里的“订单状态”或网络质量分数。:playing 表示媒体正在播放；即使因为缓冲或卡顿暂时停住，只要不是用户主动暂停，也可能仍属于 playing 语义。:paused 表示用户暂停或尚未开始。:seeking 描述正在跳转时间轴，:buffering 和 :stalled 用于表达等待资源的阶段，:muted 只说明静音状态。

用 :playing 与 :paused 标出当前媒体

先写一个不依赖新伪类也能使用的结构，让文案、播放按钮和原生控件始终存在：

准备播放
  

再把增强效果绑定到媒体元素所在的卡片：

.player-card { border: 2px solid #cbd5e1; padding: 1rem; }
.player-card:has(audio:playing) { border-color: #2563eb; }
.player-card:has(audio:paused) { border-color: #94a3b8; }
audio:muted + .player-card__state::after { content: " · 已静音"; }

这里的关键是让 CSS 只负责“看起来是什么状态”。真正的播放、暂停、切换音量仍由原生控件或 JavaScript 处理；不要因为看到蓝色边框就自动重试，也不要用动画暗示媒体一定在下载。

把 :seeking、缓冲与静音状态拆开

拖动时间轴时，:seeking 是一个独立信号；网络等待时则应展示缓冲或卡顿提示。它们不应被压缩成一个“播放失败”状态。一个稳妥的优先级是：先保留用户主动暂停，再在播放语义下叠加等待提示，最后单独展示静音。

因此，文案可以分成“正在播放”“正在调整位置”“正在等待媒体”“已静音”四类。若要兼容尚未支持这些伪类的浏览器，可监听 play、pause、seeking、waiting、stalled 和 volumechange，仅在兼容路径中添加 class；不要让事件处理和 CSS 同时维护两套相互矛盾的状态机。

用特性查询和浏览器矩阵决定上线边界

MDN 将 :playing 标注为 Baseline 2026 Newly available，并提示旧设备或旧浏览器可能不支持。因此生产样式应把新选择器放在能力判断里：

.player-card__state { color: #334155; }
@supports selector(audio:playing) {
  .player-card:has(audio:playing) .player-card__state { color: #2563eb; }
}
@supports not selector(audio:playing) {
  .player-card__state::after { content: " · 请使用播放器控件确认状态"; }
}

降级不是复制一套复杂状态机，而是保留清晰文本和原生 controls。上线前至少覆盖首次加载、播放中、用户暂停、拖动时间轴、缓冲、网络卡顿、静音和恢复声音，并记录目标浏览器是否支持 selector(audio:playing)。

相关问题

媒体伪类能替代 JavaScript 播放控制吗？不能。它们适合匹配并展示状态，播放、暂停、跳转和错误处理仍需要控件或脚本。

:playing 和 :buffering 会不会互相矛盾？不一定。播放语义可以在短暂缓冲或卡顿期间保持，界面应把它们视为可叠加状态并定义显示优先级。

旧浏览器完全不支持时怎么办？保留原生 controls 和基础文案；需要统一视觉时再用媒体事件添加兼容 class。