fieldset disabled仅禁用原生表单控件（input/select/textarea/button/output及嵌套fieldset），不作用于legend内元素、contenteditable元素、自定义组件及非表单元素；禁用后值不参与提交，且存在兼容性与无障碍陷阱。

fieldset disabled 到底禁用哪些元素

它只对原生可提交表单控件生效，且有明确白名单：input、select、textarea、button、output，以及嵌套的 fieldset（会继续向下递归）。其他一律无视：

• legend 内部的任何内容（包括 input）完全不受影响——这是 HTML 规范强制行为，不是 bug
• contenteditable="true" 的 div 或 span 不会被禁用，键盘仍可编辑
• 自定义组件（如 <myinput></myinput>）若未将 disabled 透传到底层 input，就“逃逸”禁用逻辑
• label、div、span 等非表单元素加 disabled 属性无效，浏览器直接忽略

为什么有些 input 还能点、能输入、能提交

不是属性没写上，而是被更高优先级逻辑覆盖或结构异常绕过：

• 子 input 显式写了 disabled="" 或 disabled="false" —— 只要属性存在，浏览器就视为禁用；但若 JS 动态设为 el.disabled = false，反而会覆盖父级继承，导致“该禁没禁”
• label 的 for 指向了 fieldset 外的 input，点击 label 实际触发的是外部控件
• 控件不在 fieldset DOM 子树中：比如用 position: absolute 移出视觉区域但未脱离文档流，或用了 display: contents 破坏父子关系
• 框架（Vue/React）或 Web Components 封装后，底层节点脱离原生继承链，fieldset 的禁用信号无法触达

动态控制时该用 .disabled = true 还是 removeAttribute

必须统一用属性赋值方式，避免兼容性断裂：

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

• 启用：document.querySelector('fieldset').disabled = false
• 禁用：document.querySelector('fieldset').disabled = true
• 别用 setAttribute('disabled', '')：老 Safari 中可能不触发底层状态更新
• 别用 removeAttribute('disabled')：IE ≤ 11 和 Safari ≤ 15.6 中常不重绘 UI，控件看起来灰显但实际可交互
• el.disabled = null 或 undefined 不会清除禁用状态，只认布尔值

禁用后值还提交吗？怎么判断真实禁用状态

禁用后，所有受影响控件的值**不会出现在 FormData 或 form.submit() 请求体中**，和单个 input 加 disabled 行为一致。但仅靠 el.disabled 无法判断是否被父级继承禁用：

• 用 el.matches(':disabled') —— 返回 true 表示当前不可交互（含继承），现代浏览器全支持
• 若需兼容 Safari ≤ 15.3 或 IE，得手动向上遍历：el.parentElement 是否为 disabled 的 fieldset，且确认该控件不在 legend 内
• 检查 element.hasAttribute('disabled') 是 false 但 element.matches(':disabled') 是 true，说明禁用来自父级

真正麻烦的不是怎么加 disabled，而是禁用后用户还能不能通过 Tab 进入区域、屏幕阅读器是否准确播报、以及后端有没有同步校验逻辑。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！