该用 :disabled 伪类而非 disabled 属性本身来精准控制禁用态视觉样式。它仅匹配原生可禁用元素(如 button、input 等)且带 disabled 属性时的状态,优先级高、响应动态变更,但对 div 或自定义组件无效。
:disabled 而不是 disabled 属性本身?直接写 disabled 属性会让控件不可交互、不可聚焦、不提交值,但样式上默认灰掉——这不够灵活。:disabled 伪类才是真正控制「视觉反馈」的入口,它只在元素带有 disabled 属性时匹配,且优先级高于普通选择器,适合统一覆盖禁用态外观。
常见错误是以为加了 disabled 就自动有灰色效果,结果发现自定义组件(比如用 div 模拟的开关)没反应——因为 :disabled 只对原生可禁用元素生效(button、input、select、textarea、optgroup、option),对 div 或自定义 Web Component 无效。
disabled 属性才能触发 :disabled
fieldset 上设 disabled 会使其内部所有表单控件也进入禁用态,并被 :disabled 匹配disabled 属性会实时触发 :disabled 样式重绘
:enabled 的实际价值远不止“:disabled 的反义词”:enabled 匹配所有未被禁用的可交互表单元素,包括那些根本没设 disabled 属性的元素。它的关键用途是做「状态隔离」:比如你想让启用态的按钮有悬停效果,但禁用态完全不响应 :hover,这时写 button:enabled:hover 比写一堆 button:not(:disabled):hover 更清晰、更可靠。
注意::enabled 对 input[type="hidden"]、input[type="reset"] 等本身不可交互的类型也返回 true——只要没加 disabled,它就认为“逻辑上可用”。所以别依赖它判断是否真能输入。
input[type="number"]:enabled 会匹配未禁用的数字输入框,但不会匹配 input[type="file"]:enabled(文件输入框即使未禁用,在某些浏览器中 hover 也不触发样式):disabled 一样,:enabled 不作用于非表单元素,哪怕你给 div 加了 contenteditable="true"
:enabled:invalid 是比 :invalid:not(:disabled) 更简洁的写法button:disabled 有时不生效?检查这三点最常踩的坑是样式被覆盖或选择器不匹配。CSS 优先级、元素实际状态、以及伪类支持范围都可能让预期失效。
role="button" + aria-disabled="true",但此时 :disabled 仍不生效,得用 [aria-disabled="true"]
button[disabled] 比 button:disabled 优先级略高(属性选择器 vs 伪类),建议统一用后者避免混淆fieldset:disabled 内部子元素的 :disabled 匹配有延迟,需强制重排或改用 JS 监听 fieldsets 的 disabled 变化button:disabled {
opacity: 0.5;
cursor: not-allowed;
background-color: #e0e0e0;
}
/ 避免这样写,容易漏掉动态添加 disabled 的情况 /
button[disabled] {
opacity: 0.5;
}
纯 CSS 无法监听状态变化,但 :disabled 和 :enabled 是 JS 控制 UI 反馈最轻量的搭档。重点不是“怎么加属性”,而是“加完后样式是否如预期更新”。
element.disabled = true 而不是 element.setAttribute('disabled', ''),前者更语义、兼容性更好fieldset 设 disabled 比遍历每个子控件更高效,且子控件自动获得 :disabled 匹配form.reset())后,input 的 disabled 属性不会被还原——它只还原
value 和 checked,禁用状态需手动同步复杂点在于异步状态:比如按钮点击后禁用,等 API 返回再启用。这时候要确保禁用期间用户无法重复点击,且样式立刻响应——button:disabled 的样式切换是即时的,但 JS 中若忘记在 catch 里恢复 disabled = false,按钮就会永远卡住。