css选择器中的focus-within与focus-visible用法

10次阅读

:focus-within 用于父容器监听子元素获焦,:focus-visible 专为键盘用户优化焦点样式;二者常协同使用但目的不同,需兼顾可访问性与兼容性。

css选择器中的focus-within与focus-visible用法

focus-within 适合监听「子元素获得焦点」的容器场景

当一个容器内部任意可聚焦子元素(如 、带 tabindex 的元素)被聚焦时,:focus-within 就会匹配该容器本身。它不关心焦点是否来自鼠标点击、键盘 Tab 还是脚本调用,只要子元素有焦点,父容器就“激活”。

常见错误是把它当成 :hover 的替代品,或误以为它只响应键盘焦点 —— 实际上鼠标点击 同样触发 :focus-within

  • 必须作用于**父容器**,不能直接写在可聚焦子元素上(那样没意义)
  • 支持嵌套:如果 .form 包含 .field,而 .field 里有 ,那么 .form:focus-within.field:focus-within 都会生效
  • 兼容性良好(chrome 60+、firefox 61+、safari 15.4+、edge 79+),但 IE 完全不支持
.card:focus-within {   box-shadow: 0 0 0 2px #007bff; } .card:focus-within .label {   color: #007bff; }

focus-visible 是为「仅键盘用户」优化焦点样式的现代方案

:focus-visible 解决的是老式 :focus 的经典问题:鼠标点击按钮时也显示焦点环,视觉干扰强,且对非键盘用户无意义。:focus-visible 只在浏览器**判断当前焦点由键盘操作(Tab / Shift+Tab / 空格等)触发**时才生效,自动忽略鼠标点击或触摸。

它不是独立选择器,通常和 :focus 配合使用:先用 :focus 设默认行为(比如移除丑陋的默认 outline),再用 :focus-visible 加回有意义的键盘焦点样式。

  • 不能单独依赖 :focus-visible 做功能逻辑(比如控制显隐),因为它的触发完全由 UA 决定,且可能因系统设置(如 macOS 的“按下 Tab 键以在网页中突出显示链接”开关)而关闭
  • 若同时写了 :focus:focus-visible,后者优先级更高(同层级,后声明覆盖前声明)
  • 需要搭配 outline: none 谨慎使用 —— 移除 outline 后若未提供 :focus-visible 替代样式,键盘用户将彻底失去焦点指示
button:focus {   outline: none; } button:focus-visible {   outline: 2px solid #007bff;   outline-offset: 2px; }

focus-within 和 focus-visible 经常一起用,但目的完全不同

比如一个下拉菜单组件:div.dropdown 包含触发按钮和隐藏的 ul.menu。你希望:点击按钮时展开菜单(鼠标操作),而键盘用户 Tab 到按钮后继续 Tab 进入菜单项(键盘操作)—— 这就需要两个伪类协同。

  • .dropdown:focus-within:用于在任意子元素(按钮或菜单项)聚焦时,保持整个 .dropdown 处于“激活态”,比如高亮边框、显示箭头状态
  • button:focus-visible:只给按钮加键盘专属焦点样式,避免鼠标点击时出现突兀 outline
  • 菜单项(li a)自身也要写 :focus-visible,否则键盘用户进入后看不到焦点位置

容易踩的坑是:只加了 :focus-within 却忘了给可聚焦子元素配 :focus-visible,导致键盘用户在容器内移动时焦点“消失”;或者滥用 outline: none 后没补 :focus-visible,直接违反 WCAG 2.4.7(焦点可见性)。

兼容性兜底和 polyfill 注意事项

:focus-within 的 polyfill(如 focus-within-polyfill)基本可用,但需注意:它依赖事件监听(focusin/focusout),无法捕获初始页面加载时已聚焦的元素(比如 URL 带 #my-input 锚点);而且对 contenteditable 或 Shadow dom 内部元素支持有限。

:focus-visible 的 polyfill(如 focus-visible 库)更复杂,它通过监听 mousedownkeydown 来模拟 UA 的判断逻辑,但存在竞态风险 —— 比如快速点击后立刻按 Tab,可能误判为“鼠标模式”而抑制焦点样式。

  • 生产环境建议用 @supports selector(:focus-visible) 进行特性检测,而不是全局引入 polyfill
  • 不要在 :focus-visible 中写影响布局的样式(如 heightdisplay),它可能被 UA 动态切换,造成闪烁
  • 移动端 Safari 对 :focus-visible 支持较晚(ios 15.4+),且默认不触发(需用户开启辅助功能中的“键盘”相关选项)
@supports selector(:focus-visible) {   button:focus {     outline: none;   }   button:focus-visible {     outline: 2px solid #007bff;   } }

真正难处理的不是语法,而是判断「这个交互到底该由谁响应焦点」:是容器?是触发控件?还是列表项?漏掉其中一层,键盘用户的路径就断了。

text=ZqhQzanResources