CSS field-sizing怎样让textarea随内容自动增高

做评论框或后台备注时，我以前经常先给 textarea 绑定 input 事件，再用 scrollHeight 反复改高度。这个方案能用，但还要处理初始高度、滚动条、最大高度和浏览器差异。现在可以先尝试原生 CSS：field-sizing: content 让表单控件根据内容调整首选尺寸，再用最小和最大尺寸把布局边界锁住。

textarea 为什么会需要一段自动增高逻辑

原生 textarea 有默认的行数和首选尺寸。用户输入多行文本后，内容可能被截断在滚动区域里；如果直接把高度写成固定值，短内容会留下大块空白，长内容又会迫使用户在小框里滚动。传统 JavaScript 方案通过读取 scrollHeight 解决这个矛盾，但它把尺寸计算、事件绑定和兼容处理都搬到了应用代码中。

field-sizing 改变的是表单控件的首选尺寸计算方式。设置为 content 后，input 和 textarea 可以根据内容收缩或增长；它不是一个“无限自动高度”开关，最终仍然受父容器、最小尺寸、最大尺寸和溢出策略约束。

最小配方：让 textarea 随内容增长但不撑破布局

下面的配方把“内容驱动尺寸”和“布局边界”拆开写。实际项目中，min-block-size 可以按设计稿换成固定像素值，max-block-size 则应根据页面可用空间确定。

备注

.remark-box {
  /* 让控件按文本内容调整首选尺寸，而不是永远使用固定 rows 高度 */
  field-sizing: content;
  /* 给短内容保留可点击、可阅读的最小高度 */
  min-block-size: 4.5rem;
  min-inline-size: 14rem;
  /* 长文本到达边界后留在输入框内部滚动 */
  max-block-size: 18rem;
  max-inline-size: 100%;
  overflow-y: auto;
  box-sizing: border-box;
  padding: 0.75rem;
  line-height: 1.5;
}

这里的关键不是把 rows 删除，而是不要再把它当成唯一的高度来源。它可以作为没有原生能力时的初始尺寸；在支持 field-sizing: content 的环境里，控件会根据内容重新计算首选尺寸。最大高度到达后，overflow-y: auto 让输入框内部出现滚动，而不是把相邻按钮和卡片继续往下推。

三个尺寸约束决定了体验上限

为了避免“看起来会自动长高，实际上把页面顶开”，我会同时检查下面三组约束：

如果页面是左右分栏，最好同时给控件设置 max-inline-size: 100%，否则某些很长的无空格文本可能让横向布局变得难以预测。对于聊天框，最大高度通常不应超过输入区域可视高度；对于后台备注，允许多滚动几行往往比让整张表格不断变长更稳定。

不支持 field-sizing 时怎样做 JavaScript 降级

原生能力不足时，再启用传统测量方案。判断的重点是“属性是否可用”，不是用浏览器名称做分支。下面的代码只在不支持时绑定输入事件，并且每次测量前先把高度清零，避免旧高度影响新的 scrollHeight。

降级代码的上限要和 CSS 方案保持一致，否则新旧浏览器会出现不同的表单高度。若输入框会被服务端回填，也应在绑定事件后主动调用一次测量函数，不能只等待下一次键盘输入。

我会怎样检查这套方案没有制造新问题

这类样式最容易在“短文本看起来没问题”时被误判为完成。我通常至少输入四种内容：空值、一行短句、多行带换行的长文本，以及一段没有空格的长字符串。每一种都观察输入框是否越过父容器、达到最大高度后是否还能滚动、提交按钮是否仍在预期位置。

还要特别检查全局样式。如果项目把所有 textarea 写死为 width: 100%，那么 field-sizing: content 的横向增长可能被覆盖；本篇主要解决纵向自适应时，可以明确设置 inline-size: 100%，只让块方向按内容增长。移动端还需要在真实字体和软键盘出现时确认最大高度，不要只在桌面宽屏上看效果。

• 属性检测：确认 CSS.supports('field-sizing', 'content') 的分支符合预期。
• 尺寸边界：确认最小高度、最大高度和父容器宽度都生效。
• 事件行为：回填初始值时主动测量，输入、删除和粘贴后都能更新。
• 可访问性：保留关联的 label、可见焦点样式和键盘提交路径。

什么时候适合直接采用，什么时候保留降级

如果目标浏览器集合已经覆盖当前主流版本，且输入框的主要需求是“随内容增长、达到上限后内部滚动”，原生方案值得优先采用：CSS 更短，布局意图也更清楚。若产品仍需支持较老的内嵌 WebView、企业浏览器或无法快速升级的终端，就保留能力检测和 scrollHeight 降级，不要因为新属性存在就删除旧路径。

我的取舍是让两条路径共享同一组最小高度、最大高度和溢出规则。这样降级只是替代“如何计算尺寸”，而不是重新定义交互。对输入框这种高频控件来说，边界一致比单纯少几行 JavaScript 更重要。

相关问题

field-sizing: content 会让 textarea 无限变高吗？

不会。它只改变首选尺寸计算，仍然受父容器、最小/最大尺寸和溢出规则影响。长文本场景应明确设置最大块尺寸。

为什么设置了 field-sizing，textarea 还是不增长？

先检查浏览器是否支持该属性，再检查全局 height、block-size、overflow 或组件样式是否覆盖了结果。最大尺寸已经达到时，增长停止是预期行为。

旧浏览器能不能只用 CSS 解决 textarea 自动增高？

如果目标环境不支持 field-sizing，通常需要 JavaScript 测量或组件层降级。用能力检测选择路径，比按浏览器 UA 判断更容易维护。

为什么降级代码要先把 height 设为 auto？

因为旧高度可能已经限制了内容盒。先恢复自然高度，再读取 scrollHeight，才能得到当前文本真正需要的高度。