deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

CSS field-sizing reaches all major browsers, ending the JavaScript textarea hack

Firefox 152 completes support for field-sizing across all major engines, letting textareas and inputs size themselves to their content with one line of CSS instead of a JavaScript scrollHeight listener.

CSS field-sizing reaches all major browsers, ending the JavaScript textarea hack

field-sizing, the CSS property that lets form fields grow to fit their content, is now supported across every major browser engine. According to a dev.to article by Muhammad Usman, the property shipped in Chrome 123, later in Safari 26.2, and most recently in Firefox 152, which closes the last gap. That means one of the most common small scripts in front-end work — resizing a textarea as the user types — can be replaced by a single line of CSS.

How it works

Textareas and inputs have always had a fixed size: when the content outgrew the box, the browser showed a scrollbar. field-sizing: content changes that. As the dev.to article explains, the browser calculates the field's preferred size from its actual content, so it expands when a new line is added and shrinks again when text is removed. The default value is fixed, which preserves the old behaviour.

The property is not limited to textareas. It also applies to text inputs, including variants such as number and search fields, and it respects placeholders — an empty field sizes itself to the full placeholder text. Select elements behave differently too: instead of taking the width of the longest option, they size to the currently selected option. List-box selects, meaning those with a multiple attribute or a size greater than one, expand to display all of their options.

The JavaScript it replaces

Previously, auto-growing textareas were handled with a script. The pattern described in the article attaches an input listener that first resets the field's inline height to auto — necessary so the field can shrink as well as grow — then reads its scrollHeight, the vertical space the full text actually needs, and assigns that measurement back as the new height:

js textarea.addEventListener("input", () => { textarea.style.height = "auto"; textarea.style.height = textarea.scrollHeight + "px"; });

That measurement runs on every keystroke and every deletion. It is not a complicated script, but it is JavaScript performing layout work that the browser can now do natively, and variations of it have been copied into form code for years.

Practical usage

Used on its own, field-sizing: content sizes a textarea in both dimensions, which is rarely what you want. The recipe suggested in the dev.to article combines it with minimum and maximum heights using the lh unit — the current line height — so a field can start at three lines and stop growing, with scrollbars returning once the content passes roughly ten lines:

css textarea { field-sizing: content; min-height: 3lh; max-height: 10lh; resize: none; }

A field set to full width with these constraints only grows vertically, which matches the behaviour users expect from comment boxes and chat inputs.

The resize caveat

One gotcha remains. Textareas default to resize: both, which lets users drag the corner handle to resize the field manually. Once that happens, field-sizing no longer has any effect: scrollbars reappear and the height stops tracking the content. Usman's recommendation is to pair the property with resize: none, as in the snippet above.

Why it matters

Auto-sizing textareas have been a fixture of contact forms, comment sections and chat interfaces for years, and nearly every implementation was a variation of the same scrollHeight script. With field-sizing, that script becomes unnecessary boilerplate: the browser measures and lays out the field itself, with no event listener and no manual layout writes on every keystroke. Because the property now sits in Chrome, Safari and Firefox alike — a baseline CSS feature, as the article puts it — the common case needs no JavaScript fallback. It is also part of a broader shift of CSS absorbing behaviour that used to require script, and each addition like this trims a little more JavaScript out of the average page.

  • #css
  • #web-development
  • #browsers
  • #frontend
  • #form-controls

Related posts