:focus-within能控制整行高亮,因其作用于父容器时,只要子元素(如input)获焦即触发样式;须写在父级(如label)而非input自身,且需注意浏览器兼容性与overflow、shadow DOM等限制。

focus-within 为什么能控制整行高亮
:focus-within 是 CSS 原生伪类,只要元素自身或其任意后代获得焦点(比如 被点击),该元素就会匹配。它不依赖 JS,也不需要监听事件,天然适合“父容器响应子输入框聚焦”这类场景。
常见错误是把 关键在于把样式规则作用于包裹 使用场景典型如表单行: 纯 CSS 的 Safari iOS 15.4 之前版本对 真正难的不是写对那行 CSS,而是想清楚「谁该当父容器」和「失焦边界在哪里」——这两个点错一个,效果就断在最不该断的地方。:focus-within 写在 上——没用, 自身用 :focus 就够了;真正要加的是它的**父级容器**,比如 。
overflow: hidden 且子 input 滚动出视口,部分旧版 Safari 可能触发异常行为:has() 不同,:focus-within 性能开销极低,浏览器原生优化过怎么写才让整行背景/边框一起变色
的容器,并用 :focus-within 触发:label:focus-within {
background-color: #f0f8ff;
border-left: 3px solid #2196f3;
}
。注意: 必须是 的**有效祖先**(不能被 display: contents 中断,也不能跨 shadow DOM)。
div:focus-within 包太多无关内容,否则焦点一进就全亮,体验反而乱 + ),任一获得焦点都会触发,需确认这是预期行为tabindex="-1",这会干扰 :focus-within 的判定逻辑和 JavaScript 方案比,差在哪
:focus-within 在绝大多数表单场景下更轻量、更可靠。JS 方案常靠监听 focusin/focusout 手动增删 class,但容易漏掉 click → focus → blur → click 的快速切换,或在 iframe、shadow DOM 边界失效。
blur 时判断是否移出了整行(要用 relatedTarget 和递归检查),CSS 不用操心这个:focus-within 自动生效,无绑定成本移动端软键盘弹起时的兼容问题
:focus-within 的支持不稳定:软键盘弹出后,有时不触发,有时失焦时不还原。这不是你代码写错了,是浏览器 bug。
加 onfocus="this.parentElement.classList.add('focused')",配合 JS 清除,仅针对 iOS 降级:focus-within 做关键功能(比如权限校验或提交拦截),它只是视觉反馈层
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











