在表格中为textarea设只读状态,必须直接在textarea元素上加readonly属性,而非td或tr;readonly的textarea可聚焦、复制且提交时保留值,disabled则不提交;JS控制需用readOnly=true属性,CSS用:read-only伪类并兼顾旧浏览器降级,同时添加aria-readonly="true"确保无障碍支持。

textarea 在表格中加 readonly 就行,别套在 或
上
HTML 表格里放 textarea,只读逻辑和普通页面完全一样:只对 textarea 元素本身加 readonly 属性才有效。给外层 、 甚至整个 加 readonly 属性毫无作用——浏览器直接忽略。
常见错误是把 readonly 写在 上,以为能“锁住”里面所有内容。但 不是表单控件,readonly 对它没定义行为,既不阻止编辑,也不影响语义或提交。
- ✅ 正确写法:
- ❌ 错误写法:
- ⚠️ 危险写法:
(readonly="false" 反而启用只读)
readonly 的 textarea 提交时有值,但 disabled 就没了
表格常用于数据录入或展示混合场景,比如「订单明细表」里某些列是系统生成的,需展示+提交。这时必须用 readonly,而不是 disabled。
关键区别在于表单序列化行为:
-
readonly 的 textarea:可聚焦、可复制、name 和 value 会随 FormData 或 form.submit() 一起发送
-
disabled 的 textarea:完全从表单数据流中剔除,后端收不到这个字段,哪怕它明明显示在页面上
如果你发现表格提交后某个 textarea 字段后端收不到,先检查是不是误用了 disabled。
JS 动态控制表格内 textarea 只读状态,用 readOnly = true
表格里批量操作 textarea(比如点击「切换编辑模式」按钮),JS 控制必须走 DOM 属性,不是 setAttribute。
DeepBI DHTML 页面生成器
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力:
- 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面;
- 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”;
- 提及位于 `apps/console/src/featur
下载
- ✅ 正确:
row.querySelector('textarea').readOnly = true(注意 JS 属性名是 readOnly,首字母大写)
- ❌ 错误:
el.setAttribute('readonly', 'true') 或 el.readonly = true(小写 readonly 在 Safari 等浏览器可能不生效)
- ⚠️ 检查状态也得用:
if (el.readOnly),不是 el.hasAttribute('readonly'),后者在动态切换后可能滞后
尤其要注意表格行数多时,别用 querySelectorAll('textarea') 后逐个设属性却不加防抖或节流——滚动中频繁触发可能卡顿。
:read-only 伪类能统一样式,但 IE 和旧 Safari 需降级
表格里一堆 textarea 都只读,光靠原生 readonly 属性,用户看不出区别。必须加 CSS 视觉反馈:
- ✅ 推荐写法:
textarea:read-only { background: #f9f9f9; cursor: default; }
- ⚠️ 旧浏览器不支持
:read-only(如 IE11、Safari ≤ 15.4):需 JS 检测并手动加 class,例如:if (!CSS.supports('selector(:read-only)')) { el.classList.add('readonly'); },再配 textarea.readonly { ... }
- ? 无障碍不能漏:所有
readonly 的 textarea 必须显式加 aria-readonly="true",否则屏幕阅读器读不出状态
真正容易被忽略的是:表格中 textarea 常带 rows 和 cols,设了 readonly 后仍可拖拽调整大小(resize 默认开启)。如果想彻底锁定尺寸,得额外加 resize: none。
HTML 表格里放 常见错误是把 表格常用于数据录入或展示混合场景,比如「订单明细表」里某些列是系统生成的,需展示+提交。这时必须用 关键区别在于表单序列化行为: 如果你发现表格提交后某个 表格里批量操作 生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力:
- 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面;
- 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”;
- 提及位于 `apps/console/src/featur 尤其要注意表格行数多时,别用 表格里一堆 真正容易被忽略的是:表格中 textarea,只读逻辑和普通页面完全一样:只对 textarea 元素本身加 readonly 属性才有效。给外层 、 甚至整个 加
readonly 属性毫无作用——浏览器直接忽略。
readonly 写在 上,以为能“锁住”里面所有内容。但 不是表单控件, readonly 对它没定义行为,既不阻止编辑,也不影响语义或提交。
(readonly="false" 反而启用只读)readonly 的 textarea 提交时有值,但 disabled 就没了
readonly,而不是 disabled。
readonly 的 textarea:可聚焦、可复制、name 和 value 会随 FormData 或 form.submit() 一起发送disabled 的 textarea:完全从表单数据流中剔除,后端收不到这个字段,哪怕它明明显示在页面上textarea 字段后端收不到,先检查是不是误用了 disabled。JS 动态控制表格内 textarea 只读状态,用 readOnly = true
textarea(比如点击「切换编辑模式」按钮),JS 控制必须走 DOM 属性,不是 setAttribute。
row.querySelector('textarea').readOnly = true(注意 JS 属性名是 readOnly,首字母大写)el.setAttribute('readonly', 'true') 或 el.readonly = true(小写 readonly 在 Safari 等浏览器可能不生效)if (el.readOnly),不是 el.hasAttribute('readonly'),后者在动态切换后可能滞后querySelectorAll('textarea') 后逐个设属性却不加防抖或节流——滚动中频繁触发可能卡顿。:read-only 伪类能统一样式,但 IE 和旧 Safari 需降级
textarea 都只读,光靠原生 readonly 属性,用户看不出区别。必须加 CSS 视觉反馈:
textarea:read-only { background: #f9f9f9; cursor: default; }
:read-only(如 IE11、Safari ≤ 15.4):需 JS 检测并手动加 class,例如:if (!CSS.supports('selector(:read-only)')) { el.classList.add('readonly'); },再配 textarea.readonly { ... }
readonly 的 textarea 必须显式加 aria-readonly="true",否则屏幕阅读器读不出状态textarea 常带 rows 和 cols,设了 readonly 后仍可拖拽调整大小(resize 默认开启)。如果想彻底锁定尺寸,得额外加 resize: none。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










