CSS field-sizing 怎样让文本框高度随内容变化

我最近整理评论表单时，最先遇到的不是校验，而是输入框的尺寸：单行输入框内容很短时显得空，文本域内容变长后又要么挤出布局，要么只能依赖 JavaScript 反复测量高度。现在可以先试试 CSS 的 field-sizing: content，让表单控件的首选尺寸跟着内容变化，再用最小宽度、最大宽度和最大字符数把它约束在页面能接受的范围内。

官方地址：https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/field-sizing

一句话概括：给 input 或 textarea 设置 field-sizing: content，控件会尝试包住当前内容；文本域在横向空间达到上限后会继续增加行高，达到高度边界后再出现滚动条。它不是“无限自动变大”，而是“内容驱动尺寸 + CSS 边界约束”。

field-sizing: content 改变的到底是什么

这个属性改变的是表单控件的默认首选尺寸行为。默认值 fixed 仍按控件自己的固定首选尺寸展示；换成 content 后，浏览器会参考输入内容重新计算尺寸。对单行输入框来说，文字增加时通常先变宽；对文本域来说，宽度到达限制后会通过换行增加高度。

我觉得它最有价值的地方，是把“内容变化”交还给 CSS。页面不需要先监听每次输入，再读取 scrollHeight，也不必为了一个普通的评论框维护一套测量和回写逻辑。下面这张原创说明图把固定尺寸、内容尺寸和约束属性放在一起，便于先建立正确预期。

最小示例可以这样写：

  昵称
  评论
  

.comment-form input,
.comment-form textarea {
  /* 让控件根据内容计算首选尺寸，而不是永远使用固定首选尺寸。 */
  field-sizing: content;
  /* 防止短内容把控件压得过窄。 */
  min-width: 12ch;
  /* 防止长内容把同一行布局撑破。 */
  max-width: min(100%, 42rem);
}

.comment-form textarea {
  /* 文本域仍保留一个可读的初始高度。 */
  min-height: 4lh;
  /* 高度上限到达后由控件内部滚动承载超长内容。 */
  max-height: 16lh;
}

这里的 maxlength 负责限制用户最多输入多少字符，min-width 与 max-width 负责限制控件尺寸。三者解决的是不同问题，不能互相替代。

输入框怎样做到自然变宽又不撑破布局

单行 input 是最容易看到效果的场景。启用 content 后，短文本会让控件收缩到接近内容的宽度，长文本会让控件尝试变宽。实际页面不能只写一行属性就结束，因为没有最小宽度时，空值或光标状态可能让输入框窄到几乎不可用；没有最大宽度时，长昵称、邮箱或 URL 又可能挤压旁边的按钮。

.profile-form input[type="text"],
.profile-form input[type="email"] {
  /* 内容驱动宽度，但把最小和最大范围锁在组件内部。 */
  field-sizing: content;
  min-inline-size: 14ch;
  max-inline-size: 100%;
}

/* 字符数限制属于 HTML 属性，不写成不存在的 CSS 属性。 */
.profile-form input[type="email"] {
  max-inline-size: min(100%, 32rem);
}

字符数限制属于 HTML 属性，真正限制输入长度要用 maxlength。生产代码应把它放回控件：

另外，带 placeholder 的输入框可能会先按占位文本显示出一个较宽的首选尺寸；用户开始输入后，尺寸再根据真实内容变化。若你希望表单在初始状态也整齐，建议保留 min-inline-size，不要把宽度完全交给一段可能很长的占位文案。

textarea 为什么会从变宽转为增加高度

文本域的变化更符合实际表单需求：内容不长时，它会尝试在行内方向容纳文字；达到 max-width 或容器宽度后，继续输入的内容会换到下一行，于是控件转为在块方向增加高度。如果高度也受到 max-height 限制，浏览器最终会显示滚动条，而不是无限向下推动页面。

.feedback textarea {
  /* 让文本域先按内容调整尺寸。 */
  field-sizing: content;
  /* 宽度到达上限后，更多文字通过换行增加行数。 */
  min-inline-size: 20ch;
  max-inline-size: 100%;
  /* 用行高单位给高度留出可读范围。 */
  min-block-size: 5lh;
  max-block-size: 18lh;
  /* 超过高度上限后只在控件内部滚动。 */
  overflow: auto;
}

需要注意的是，rows 和 cols 会影响文本域的默认首选尺寸，但在 field-sizing: content 下不应再把它们当作最终尺寸控制器。更稳定的做法是保留语义上合理的 rows 作为 HTML 默认值，再通过 CSS 的最小、最大尺寸表达布局边界。

怎样给不支持 field-sizing 的浏览器留回退

MDN 当前将这个属性标为较新的跨浏览器能力，但旧设备和旧浏览器仍可能不支持。我的处理方式是先写一个所有浏览器都能工作的固定尺寸，再用 @supports 覆盖支持新属性的环境。这样即使增强样式没有生效，用户仍然拥有一个可输入、可提交的表单。

.feedback textarea {
  /* 基础回退：没有 field-sizing 时也保持可用高度。 */
  width: 100%;
  min-height: 8rem;
  resize: vertical;
  box-sizing: border-box;
}

@supports (field-sizing: content) {
  .feedback textarea {
    /* 支持时再启用内容驱动尺寸，其他回退规则继续保留。 */
    field-sizing: content;
    min-block-size: 5lh;
    max-block-size: 18lh;
  }
}

这里不需要用 JavaScript 复制一套“自动高度”逻辑。只有当产品明确要求复杂的测量策略、跨控件联动或特殊动画时，才值得引入脚本；普通输入和评论场景先用 CSS 原生能力，代码量和故障面都会更小。

这几个属性组合时最容易踩什么坑

第一，给同一个控件同时写固定的 width 或 height，会重新把尺寸锁死，抵消 field-sizing: content 的伸缩效果。若需求是“能伸缩但不能太大”，优先使用 min-width、max-width、min-height 和 max-height。

第二，不要为了追求自动变高而去掉 label、字符上限和滚动边界。尺寸变化服务的是阅读和输入体验，语义关联、可访问性和布局稳定性仍然要由 HTML 与 CSS 一起负责。

第三，先区分“控件尺寸变化”和“用户输入长度限制”。maxlength 会阻止输入继续增加，也会间接阻止控件继续因为字符数增长；但它不是尺寸属性，不能用来代替 max-width 或 max-height。

我的结论：适合渐进增强的原生表单

如果页面需要一个会随内容变化的昵称框、搜索框、短备注或评论文本域，field-sizing: content 值得先放进基础方案：用 content 负责自然伸缩，用 min/max 负责边界，用 maxlength 负责输入上限，再用 @supports 保留固定尺寸回退。

它最适合“尺寸变化本身就是体验的一部分”的小型表单，不适合完全不能改变布局的固定表格、工具栏或需要严格对齐的密集录入界面。对我来说，真正省下来的不是几行 CSS，而是少维护一套监听输入、计算高度、处理滚动条的脚本。

常见问题

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

不能。它只让控件倾向于按内容调整尺寸；容器宽度、max-width、max-height 等边界仍然生效，超过高度上限后会出现滚动条。

为什么设置了 field-sizing 但 input 还是固定宽度？

优先检查是否同时设置了固定的 width，以及选择器是否被更高优先级的规则覆盖。还要确认当前浏览器支持该属性；不支持时应按回退样式显示。

rows 和 cols 还要不要写？

可以保留它们表达 HTML 默认值和无增强环境下的基础尺寸，但不要把它们当作启用 field-sizing: content 后的唯一尺寸控制手段；最终边界更适合用 CSS 的最小和最大尺寸表达。

把这几个边界写清楚后，表单就能在“内容自然展开”和“页面不被撑破”之间取得平衡。