DEV Community

Vishal Singh
Vishal Singh

Posted on

CSS field-sizing Is Baseline 2026: Auto-Growing Inputs and Textareas Without JavaScript

#css #webdev #frontend #a11y

Forms often start with a sizing compromise.

An input is wide enough for the average value but wastes space for short values. A textarea begins at a fixed height and either shows a scrollbar too early or needs JavaScript to measure scrollHeight after every edit.

CSS field-sizing gives form controls a content-based sizing mode. With one declaration, an input can grow with its value and a textarea can expand as the user types.

MDN marks field-sizing as Baseline 2026 Newly available since June 2026. That means the latest core browser versions support it, but older browsers and devices still exist. The practical approach is progressive enhancement: keep a usable default, add content sizing where supported, and set defensive minimum and maximum sizes.

The two sizing modes

The property has two keyword values:

field-sizing: fixed;
field-sizing: content;
Enter fullscreen mode Exit fullscreen mode

fixed is the initial value. The control uses its normal preferred size, along with CSS dimensions and HTML attributes such as size, rows, and cols.

content tells the control to adjust its preferred size around its current content.

The smallest useful enhancement is:

input,
textarea,
select {
  field-sizing: content;
}
Enter fullscreen mode Exit fullscreen mode

That line changes the sizing model, but it is not enough for production. An empty text field can collapse close to the width of its caret, while a long value can push the layout much farther than intended. Content-based sizing needs boundaries.

Build an auto-growing textarea

Start with ordinary, accessible HTML:

<label for="reply">Reply</label>
<textarea
  id="reply"
  name="reply"
  placeholder="Write your reply"
></textarea>
Enter fullscreen mode Exit fullscreen mode

Then keep a dependable fallback and enhance it:

textarea {
  box-sizing: border-box;
  inline-size: 100%;
  min-block-size: 6rem;
  max-block-size: 18rem;
  resize: vertical;
}

@supports (field-sizing: content) {
  textarea {
    field-sizing: content;
    inline-size: 100%;
  }
}
Enter fullscreen mode Exit fullscreen mode

In an unsupported browser, the textarea remains a normal six-rem-high control that the user can resize vertically.

In a supporting browser, its block size grows with the entered content until it reaches max-block-size. After that limit, the control can scroll instead of expanding forever.

This replaces a common JavaScript pattern:

textarea.addEventListener("input", () => {
  textarea.style.height = "auto";
  textarea.style.height = `${textarea.scrollHeight}px`;
});
Enter fullscreen mode Exit fullscreen mode

Removing that measurement loop means less event code and fewer layout reads. It also lets CSS remain responsible for presentation.

Let a short input grow with its value

Content sizing is also useful for compact fields such as a coupon code, quantity, slug, or inline editable label.

<label for="project-slug">Project slug</label>
<input
  id="project-slug"
  name="project-slug"
  type="text"
  value="docs"
  maxlength="40"
>
Enter fullscreen mode Exit fullscreen mode 
@supports (field-sizing: content) {
  #project-slug {
    field-sizing: content;
    min-inline-size: 10ch;
    max-inline-size: min(32ch, 100%);
  }
}
Enter fullscreen mode Exit fullscreen mode

The input starts at a useful minimum, grows with the value, and stops before it can break its container. maxlength also limits the amount of accepted text, although layout limits should still exist independently.

Use logical properties such as inline-size and block-size when the component may appear in different writing modes. They describe the text flow rather than assuming that width is always horizontal.

Understand the textarea growth order

A textarea with field-sizing: content can grow in both directions.

If its inline size is unconstrained, it may first grow wider with the content. Once it reaches an inline constraint, text wraps and the textarea begins growing in the block direction. When the block-size limit is reached, scrolling becomes necessary.

For most form layouts, the intended behaviour is simpler: keep the textarea as wide as its container and let only its height respond to content.

@supports (field-sizing: content) {
  .message-field {
    field-sizing: content;
    inline-size: 100%;
    min-block-size: 5lh;
    max-block-size: 14lh;
  }
}
Enter fullscreen mode Exit fullscreen mode

The lh unit follows the element's line height, so the limits describe an approximate number of text lines instead of unrelated pixels.

Placeholders participate in sizing

A placeholder is content for intrinsic sizing. A long placeholder can make an otherwise empty control much wider.

<input
  type="email"
  placeholder="name@company.example"
>
Enter fullscreen mode Exit fullscreen mode

With field-sizing: content, that placeholder influences the initial preferred width. When the user starts typing, the field can resize around the actual value.

Do not use a long placeholder as a substitute for instructions. Keep a visible label, place supporting guidance beside the control, and set min-inline-size and max-inline-size so placeholder copy cannot dictate the entire layout.

HTML sizing attributes change meaning

The HTML size attribute normally influences the preferred width of an input. rows and cols normally influence a textarea's starting size.

When field-sizing: content controls the preferred size, those attributes no longer provide the same sizing behaviour. Put the production boundaries in CSS instead:

.profile-bio {
  min-inline-size: 20ch;
  max-inline-size: 100%;
  min-block-size: 5lh;
  max-block-size: 16lh;
}
Enter fullscreen mode Exit fullscreen mode

Keep semantic HTML attributes that have independent value, such as maxlength, required, autocomplete, and the correct input type.

Select controls can shrink to the chosen option

For a regular <select>, the browser normally reserves enough width for the longest option. With content sizing, the closed control can adjust to the currently selected option.

@supports (field-sizing: content) {
  select.compact {
    field-sizing: content;
    min-inline-size: 8ch;
    max-inline-size: 100%;
  }
}
Enter fullscreen mode Exit fullscreen mode

This can help compact toolbars, but changing width after every selection can also make surrounding controls move. Use it only where that movement is acceptable, and test long localized option labels.

Multi-select list boxes behave differently: content sizing can make them large enough to display their options without the usual scrolling. That may be useful for a short fixed list and harmful for a long dynamic one.

Fixed dimensions can defeat the feature

If you set a fixed width or height, you are reintroducing a fixed size. Prefer minimums and maximums around content sizing.

/* Flexible */
input {
  field-sizing: content;
  min-inline-size: 8ch;
  max-inline-size: 28ch;
}

/* This prevents inline growth */
input.fixed-example {
  inline-size: 18rem;
}
Enter fullscreen mode Exit fullscreen mode

The property is not magic layout containment. The parent grid or flex layout, available space, padding, borders, fonts, placeholder, and overflow rules all affect the final result.

Accessibility checks still matter

Auto-sizing can remove JavaScript, but it does not remove form-design responsibilities.

Test the component with:

  • keyboard-only navigation
  • browser zoom at 200% and 400%
  • increased text size and spacing
  • long unbroken strings
  • autofilled values
  • validation messages
  • localized labels and placeholders
  • right-to-left and vertical writing modes where relevant

Keep an associated <label>. Do not hide overflow merely to preserve a compact design. Make sure focus indicators remain visible as the control changes size. For textareas, retaining resize: vertical gives users a manual option when your automatic limits do not match their needs.

Also watch for layout shift. A field that grows inside a toolbar or card can move buttons and surrounding content. Content-based sizing should improve the interaction, not surprise the user after every character.

A safe rollout plan

  1. Choose one field currently using a JavaScript auto-resize handler.
  2. Keep the existing usable dimensions as the default.
  3. Add field-sizing: content inside @supports.
  4. Define minimum and maximum inline and block sizes.
  5. Test empty, placeholder, typical, maximum, and autofilled values.
  6. Test zoom, localization, keyboard use, and small containers.
  7. Remove the JavaScript measurement loop only after the CSS path meets your browser-support policy.

Conclusion

field-sizing turns a common scripted behaviour into a native sizing option.

The property is small, but the implementation decision is still a design decision. An input should not collapse to a caret or expand across the page. A textarea should not grow without limit. A select should not shift an entire toolbar unexpectedly.

Use content sizing as progressive enhancement, surround it with sensible constraints, and test the states that real form controls experience. When those boundaries are in place, one line of CSS can replace a surprising amount of measurement code.

Sources

Top comments (0)