CSS field-sizing 不支持时怎么给自适应输入框做降级

我在把一个标签编辑表单从固定宽度改成“文字短就收缩、文字长就增长”时，最先想到的是 field-sizing: content。它确实能让支持它的浏览器按控件内容调整尺寸，但兼容性不能靠“属性写上了”来保证：不支持的浏览器会忽略这条声明，页面仍然需要一个可用的默认尺寸。

比较稳妥的做法是把它当作渐进增强：默认样式先保证输入框有最小宽度、最大宽度和换行/溢出策略，再用 @supports 覆盖支持环境。单行输入只需要接近内容宽度时，可以用伪元素镜像；必须和真实文本宽度精确同步时，再增加一小段 JavaScript 测量。

先把原生能力包在 @supports 中

MDN 当前的属性说明把 field-sizing 定义为控制带有默认首选尺寸的表单控件，content 允许控件按内容收缩或增长，fixed 则保持固定尺寸。由于旧浏览器可能完全不认识这个属性，兼容写法应该先提供默认规则，再在能力存在时覆盖。

  标签
  

.tag-editor {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  max-width: 100%;
}

.tag-input {
  /* 旧浏览器也能得到稳定的起始尺寸。 */
  box-sizing: border-box;
  inline-size: 12rem;
  min-inline-size: 8rem;
  max-inline-size: min(100%, 28rem);
  padding: 0.45rem 0.65rem;
}

@supports (field-sizing: content) {
  .tag-input {
    /* 只有支持该属性时，才让输入框跟随内容变化。 */
    field-sizing: content;
    inline-size: auto;
    min-inline-size: 8rem;
    max-inline-size: min(100%, 28rem);
  }
}

这里的关键不是把默认规则删掉，而是让默认规则本身就能交付。min-inline-size 避免空值或短值把控件压到接近光标宽度，max-inline-size 则防止长文本把一行布局顶出容器。支持原生能力的浏览器再使用 content，不支持的浏览器会自然留在固定起始宽度。

先确认固定宽度是不是自己把自适应关掉了

如果支持检测已经通过，但输入框仍然不增长，优先检查是不是在后面的选择器中重新设置了固定 width 或 height。MDN 也特别提醒，固定尺寸会重新施加固定布局；与 field-sizing: content 配合时，更适合使用 min-width、max-width 这类边界，而不是再次指定固定宽度。

.tag-input {
  field-sizing: content;
  min-inline-size: 8rem;
  max-inline-size: 28rem;
  /* 不要在这里再写 inline-size: 12rem 覆盖内容尺寸。 */
}

.tag-input:focus {
  /* 只改变外观，不改变控件的尺寸计算。 */
  outline: 2px solid #4f46e5;
  outline-offset: 2px;
}

排查时可以把问题拆成三个层次：第一，@supports (field-sizing: content) 是否匹配；第二，最终规则中是否还有固定尺寸；第三，父容器是否有 overflow、弹性收缩或网格轨道限制。不要一看到“没有变宽”就直接增加 JavaScript，很多时候只是约束顺序或容器边界导致的预期结果。

不支持时，固定尺寸通常是最稳的降级

如果产品并不要求输入框随着每个字符变化，只是希望新浏览器的短文本看起来更紧凑，那么固定尺寸就是足够好的回退。它没有测量误差，也不受字体加载、中文字符宽度和缩放比例影响，交互和可访问性更容易维护。

.legacy-input {
  /* 默认方案保证键盘输入、焦点和错误提示都有稳定空间。 */
  box-sizing: border-box;
  inline-size: 14rem;
  max-inline-size: 100%;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

@supports (field-sizing: content) {
  .legacy-input {
    /* 新环境增强为内容尺寸，但仍保留上下限。 */
    field-sizing: content;
    inline-size: auto;
    min-inline-size: 8rem;
    max-inline-size: 28rem;
  }
}

这种方式适合搜索框、表格筛选项、表单字段等对布局稳定性要求更高的场景。即使旧浏览器无法自适应，用户仍能完整输入，文本是否完整可以交给焦点状态、辅助说明或提交后的校验来表达。

单行输入可以用伪元素镜像内容

如果确实想让旧浏览器中的单行输入接近内容宽度，又不想为每个输入事件引入脚本，可以让一个不可见的伪元素承载同样的文本。输入框本身仍然负责语义、键盘和表单提交，镜像元素只参与外层宽度计算。

.mirror-field {
  display: inline-grid;
  max-inline-size: 100%;
  min-inline-size: 8rem;
  max-width: 28rem;
}

.mirror-field__text,
.mirror-field__input {
  /* 两层必须共享字体、内边距和边框，宽度才有可比性。 */
  grid-area: 1 / 1;
  box-sizing: border-box;
  font: inherit;
  letter-spacing: inherit;
  padding: 0.45rem 0.65rem;
  white-space: pre;
}

.mirror-field__text {
  /* 镜像文本只撑开网格，不暴露给辅助技术。 */
  visibility: hidden;
  min-inline-size: 8rem;
  max-inline-size: 28rem;
  overflow: hidden;
}

.mirror-field__input {
  min-inline-size: 8rem;
  max-inline-size: 28rem;
}

@supports (field-sizing: content) {
  .mirror-field__text {
    display: none;
  }

  .mirror-field__input {
    /* 原生能力存在时，移除镜像层，避免两套逻辑同时生效。 */
    field-sizing: content;
    inline-size: auto;
  }
}

const field = document.querySelector('.mirror-field');
const input = field.querySelector('.mirror-field__input');
const mirror = field.querySelector('.mirror-field__text');

function syncMirror() {
  // 用不换行空格避免输入为空时镜像层完全塌陷。
  mirror.textContent = input.value || input.placeholder || '\u00a0';
}

input.addEventListener('input', syncMirror);
syncMirror();

伪元素镜像的代价是样式必须严格同步：字体、字重、字距、内边距和边框只要有一项不一致，输入框就会出现细小偏差。它适合单行、短文本、对测量精度要求不高的场景；对于多行 textarea、复杂字体或需要精确处理滚动的控件，不建议把它当万能方案。

需要精确同步时再用 JavaScript 测量

当输入框必须严格跟随文字宽度，或者需要在旧浏览器中复刻更接近 field-sizing: content 的行为时，可以使用隐藏的测量节点。重点是只在输入事件时更新，并且把测量节点的字体属性复制完整。

.measure-probe {
  /* 测量节点不参与布局，也不接受鼠标操作。 */
  position: absolute;
  visibility: hidden;
  white-space: pre;
  inset: 0 auto auto 0;
}

.measured-input {
  box-sizing: border-box;
  min-inline-size: 8rem;
  max-inline-size: 28rem;
}

const input = document.querySelector('.measured-input');
const probe = document.querySelector('.measure-probe');

function syncInputWidth() {
  // 复制会影响文字宽度的属性，避免测量结果与真实输入不一致。
  const styles = getComputedStyle(input);
  probe.style.font = styles.font;
  probe.style.letterSpacing = styles.letterSpacing;
  probe.style.paddingInline = styles.paddingInline;
  probe.textContent = input.value || input.placeholder || '\u00a0';

  // 把宽度限制在 CSS 设定的上下限内，避免长文本撑破布局。
  const min = parseFloat(styles.minInlineSize) || 0;
  const max = parseFloat(styles.maxInlineSize) || Number.POSITIVE_INFINITY;
  const measured = probe.getBoundingClientRect().width;
  input.style.inlineSize = `${Math.min(Math.max(measured, min), max)}px`;
}

input.addEventListener('input', syncInputWidth);
window.addEventListener('resize', syncInputWidth);
syncInputWidth();

脚本测量比镜像层更精确，但也带来维护成本：字体异步加载后可能需要重新测量，响应式容器改变时要处理 resize，而且 getBoundingClientRect() 的结果会受到缩放和字体渲染影响。对输入框设置宽度时要保留 CSS 上限，不能只按文本测量值直接写回。

三种降级方案应该怎么选

我的取舍是：默认先交付固定尺寸，再用 @supports 开启原生能力；只有产品交互真的要求旧浏览器也要动态变宽，才增加镜像或测量。这样新浏览器得到更自然的表单体验，旧浏览器也不会因为一个增强属性失效而丢掉可用性。

发布前用几个边界场景反向确认

不要只输入一串英文就结束检查。至少覆盖空值、占位符、短中文、长中文、达到 maxlength、父容器很窄、浏览器缩放和字体加载后重新排版。对于 textarea，还要单独确认高度增长、滚动条和提交时的换行是否符合预期。

• 能力：不支持 field-sizing 时，默认规则仍有明确的最小和最大尺寸。
• 布局：长文本不会突破父容器，焦点轮廓和错误提示不会被裁掉。
• 同步：使用镜像或测量时，字体、字距、内边距和响应式尺寸变化都有处理。
• 选择：能说明为什么当前表单选择固定尺寸、CSS-only 或 JavaScript，而不是三套方案叠加。

相关问题

field-sizing: content 为什么看起来没有生效？先看支持检测和最终计算样式，再检查后续规则是否重新设置了固定宽度或高度，以及父容器是否限制了可用空间。

field-sizing 支持后还需要 JavaScript 吗？如果目标浏览器范围已经覆盖且只需要表单控件自适应，通常不需要；脚本只适合仍有旧浏览器或特殊测量需求的产品。

伪元素镜像能处理 textarea 吗？可以另做多行测量，但换行、滚动和高度上限会显著增加复杂度；普通表单优先使用固定回退或原生能力。