HTML代码中textarea只读与禁用效果对比-html教程-PHP中文网

readonly 属性的 textarea 仍可提交，因其仅阻止用户输入但不剔除于表单序列化；disabled 则彻底排除在提交之外；contenteditable 元素必须设 contenteditable="false" 才真正禁用编辑。

html代码中textarea只读与禁用效果对比

textarea readonly 属性为什么值还能提交

因为 readonly 是 HTML 层面的只读约束，不参与表单序列化逻辑的剔除——它只阻止用户输入，但保留字段在 form.submit() 或 FormData.append() 中的可见性。只要 name 存在、元素未被 disabled，它的 value 就会被提交。

常见错误现象：后端收不到 textarea 值，结果发现前端误用了 disabled；或者用了 readonly 却没设 name，导致提交时字段名丢失。

readonly 元素仍可 focus()、支持 select()、触发 focus 和 input 事件（只是不更新值）
JS 仍能直接赋值：el.value = 'new content'，readonly 不拦截脚本修改
若需视觉灰化，得手动加 CSS：textarea[readonly] { background: #f5f5f5; cursor: not-allowed; }

textarea disabled 属性为什么后端收不到数据

disabled 的本质是让元素退出表单控件集合——浏览器在构造 FormData 或序列化 form 时，会跳过所有 disabled 元素，无论你 JS 里有没有改过它的 value。

典型误用场景：想“禁用编辑但保留提交”，却只加了 disabled；或 React/Vue 中绑定 :disabled="isLocked" 后忘了同步维护隐藏字段。

Html To Pdf

使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。

下载

disabled 元素无法获得焦点，el.focus() 静默失败，tabindex 失效
键盘事件（包括 paste、enter）全部被拦截，连 input 事件都不触发
若必须“禁用但提交”，得配一个同名 <input type="hidden">，并在 JS 中保持两者值同步

contenteditable 的 textarea 怎么真正锁住

原生 textarea 支持 readonly 和 disabled，但富文本容器（如 div[contenteditable="true"]）完全不响应这两个属性。靠 pointer-events: none 或 user-select: none 只能防鼠标，无法阻止键盘粘贴、回车换行等编辑行为。

正确做法只有一条：contenteditable="false"。移除该属性或设为 false 才算真正关闭编辑能力。

动态切换时，直接操作 DOM：el.contentEditable = 'false'（注意字符串值，不是布尔）
不要依赖 CSS 遮罩——它对键盘输入无效，且 screen reader 可能误读为可交互
某些编辑器（如 HTMEditor）会替换原始 textarea，此时要操作其外层容器，而非原始元素

React/Vue 中绑定只读状态容易踩的坑

框架语法糖掩盖了底层差异，导致语义错配。Vue 写 :readonly="true" 对 <select></select> 无效；React 必须用 readOnly（驼峰），写成 readonly={true} 会变成字符串属性，浏览器当成真值处理。

更隐蔽的问题：表单验证库（如 Yup）默认校验 readonly 字段，但跳过 disabled 字段——如果你靠 disabled “绕过校验”，实际可能漏掉业务规则。

Vue 中：<input :readonly="isViewOnly"> ✅，但 <select :readonly="true"></select> ❌（无效）
React 中：<textarea readonly></textarea> ✅，<textarea readonly></textarea> ❌（属性名错误）
SSR 场景下，服务端渲染 disabled，客户端 JS 没同步 hidden 字段，就会造成提交数据缺失