· 4 min read
The textarea can measure itself
Firefox 152 closes the last major-browser gap for CSS field-sizing, so ordinary textarea autosize handlers can give layout back to the browser.
Open an auto-growing composer and there is a good chance its input handler performs a tiny ritual: erase the textarea's inline height, read scrollHeight, then write the answer back in pixels. Every keystroke asks JavaScript to make layout report a fact that CSS ought to know already.
Firefox 152, released June 16, added field-sizing. That closes the last major-engine gap after Chrome and Safari. The useful consequence is almost comically small: a common hook can become one declaration.
composer.ts
-const field = document.querySelector("textarea")!;-const resize = () => {- field.style.height = "0";Review
Clear the previous answer so the field can shrink as well as grow.
- field.style.height = `${field.scrollHeight}px`;Review
Read layout after changing style, then copy the measured pixels back into style.
-};-field.addEventListener("input", resize);Review
Input is one trigger. Resets, programmatic values, fonts, and width changes need their own path.
-resize();+textarea {+ field-sizing: content;Review
Let intrinsic sizing respond whenever layout or content changes.
+}The hook was chasing layout#
The old pattern is old enough to have its own fossil record. A 2017 CSS Working Group issue calls JavaScript autosizing tricky because scrollbars disturb the calculation, and one comment supplies the familiar workaround: assign inherit, read scrollHeight, append px. The group resolved that November to add content sizing for textareas.
A robust hook has to notice more than typing. Change the field's width and the same sentence wraps onto new lines. Load a different font, restore a form, replace the value from application state, alter padding, or let placeholder text use larger metrics, and the required height moves without an input event. Why was the application measuring its own box after every letter?
The current CSS Forms specification gives the browser the rule directly: fixed keeps the host language's default preferred size, and content makes the user agent derive intrinsic size from whatever is in the box. The text wraps, the field grows. Nothing is left for application code to keep synchronized.
Content still needs fences#
Pure content sizing can turn an empty field into a tiny target and a long draft into the whole viewport. Chrome's implementation guide warns about both ends, so the useful rule includes boundaries rather than pretending one property finished the component:
.composer { inline-size: 100%; field-sizing: content; min-block-size: 3lh; max-block-size: 12lh; overflow-y: auto; resize: vertical;}- 1A fixed inline size lets wrapping decide how many lines the field needs.
- 2The browser derives the intrinsic block size from the current contents instead of the default textarea size.
- 3An empty composer keeps enough room to look and behave like an input rather than a caret in a border.
- 4After twelve line boxes, a long draft stops growing and begins to scroll.
- 5The user keeps the native vertical resize handle when the automatic answer is uncomfortable.
Those limits keep the floor in CSS, where the sizing policy now lives. The specification says content ignores the textarea's default preferred size, so an explicit minimum preserves the initial shape. At the other end, the maximum gives the control a scroll boundary instead of letting one pasted log rearrange the page.
I have not audited how many production editor hooks can disappear immediately. Older browser floors, animation requirements, mirrored overlays, and rich-text behavior will keep some of them alive. For an ordinary textarea, unsupported browsers ignore the declaration and retain their fixed default size. A legacy autosize requirement can keep its script behind a feature check rather than making every browser pay for it.
The awkward cases belong lower down#
Safari's 26.2 release notes announce field-sizing: content and, farther down the same page, record a fix for larger placeholder text failing to expand a field's height. I can think of no better argument for handing the calculation to the browser. Placeholder metrics are now a WebKit bug with a shared fix, rather than another edge case for every application hook to discover on its own.
Chrome shipped the property in version 123, Safari followed in December 2025, and Firefox completed the set this June. The engines will still disagree at the edges, and the property is young enough that testing real fonts, zoom, writing modes, and maximum sizes matters. At least those tests now exercise layout itself rather than a private imitation wired to one event.
The 2017 CSSWG issue still contains the workaround in a comment: set a height, read scrollHeight, append pixels. A few screens below it, the meeting bot records the decision to add textarea sizing. The linked specification now defines field-sizing: content, and in a current composer those two JavaScript lines are the part of the diff that disappears.