:valid-within 不存在，是误传概念；浏览器仅支持单元素 :valid/:invalid，表单组整体验证需 javascript 实现，监听 input/blur 事件并调用 checkvalidity() 判断。
什么是 :valid-within？它根本不存在
浏览器目前（截至 2024 年中）**不支持** :valid-within 这个伪类。它既不是 css 规范中的标准特性，也不在任何主流引擎（chrome、firefox、safari、edge）中实现。如果你在文档或某篇博客里看到它被当作可用功能演示，那大概率是混淆了概念、笔误，或是基于某个未落地的提案草稿。
:valid 和 :invalid 只作用于单个表单控件
原生表单验证反馈依赖的是每个 <input>、<select></select>、<textarea></textarea> 自身的 :valid/:invalid 状态。它们不会“感知”兄弟元素，更不会聚合判断整个 <form></form> 或某个 <fieldset></fieldset> 是否整体有效。
常见错误现象：
– 给 <form></form> 写 form:valid { … }，样式完全不生效
– 以为给 <div class="group"> 加 <code>.group:valid 就能响应内部所有字段校验结果，实际无效
-
:valid触发前提是该元素有required、type="email"等可验证属性，且值符合规则 - 空值 +
required→:invalid；填了合法邮箱 →:valid；但旁边另一个必填项为空，不影响前者状态 - 没有 js 干预时，浏览器**不会主动计算“组内全部有效”这个逻辑**
想实现“表单组整体验证通过”的视觉反馈，得靠 JavaScript
核心思路：监听组内所有相关字段的 input 和 blur 事件，手动检查每个字段的 checkValidity() 结果，再统一控制容器的 class。
立即学习“前端免费学习笔记（深入）”；
使用场景：
– 注册页的“密码+确认密码”区块
– 地址填写区（省市区三级联动+详细地址）
– 多步骤表单中某一步的子模块
- 别直接监听
form.submit—— 用户还没提交时就该有实时反馈 - 用
Element.checkValidity()判断单个字段，比读validity.valid更可靠（会触发隐式验证） - 推荐把验证逻辑封装成函数，例如
isGroupValid(groupEl)，避免重复遍历 - 给容器加一个临时 class 如
group-valid，CSS 写.group.group-valid { … }
const pwdGroup = document.querySelector('.password-group'); const inputs = pwdGroup.querySelectorAll('input'); <p>function updateGroupValidity() { const allValid = Array.from(inputs).every(el => el.checkValidity()); pwdGroup.classList.toggle('group-valid', allValid); }</p><p>inputs.forEach(input => { input.addEventListener('input', updateGroupValidity); input.addEventListener('blur', updateGroupValidity); }为什么不用 :has() 搞定？它现在也做不到
有人会想到用新出的 :has() 伪类，比如 .group:has(input:not(:valid)) 表示“组内存在无效项”，反过来推导整体有效。但问题在于：
-
:has()**不支持:valid/:invalid作为子选择器**（Chrome 125+ 开始支持部分组合，但:valid仍被排除） - 即使未来支持，
:has(input:valid)只表示“至少一个有效”，无法表达“全部有效” -
:has()是性能敏感选择器，频繁重排下可能卡顿，不适合高频输入场景 - 当前 Safari 完全不支持
:has()，兼容性风险高
所以，别等 CSS “自动搞定”，该写几行 JS 的地方，老老实实写。重点是把验证逻辑收口、复用，而不是强求用纯 CSS 实现本不属于它的职责。
最容易被忽略的一点：很多开发者只在用户输入后检查，却忘了初始加载时也要调用一次验证函数——否则页面刚打开，容器上就没有正确的初始状态 class。