Field-sizing changes how supported controls choose their preferred size. The content value lets a text input or textarea size to its contents, subject to constraints supplied by the containing layout and CSS min or max sizes.
CSS field-sizing: let a note grow within firm limits
When to use it
A reviewer writes a short exception note beside other form fields. A rigid two-line box becomes awkward when the note grows, but an unbounded box can push the submit action far below the screen. Give the textarea a useful minimum, an upper bound, and a width that fits the form; then opt into content sizing where supported. The sample retains a usable block size if the new property is ignored. Test an empty note, a long pasted paragraph, high zoom, and the case where the field reaches its maximum and starts scrolling. The HTML label and any length rule remain separate. Do not set a fixed height after requesting content sizing and expect the control to keep growing. If the note is required, validate that requirement in the form and service.
.exception-note { box-sizing: border-box; inline-size: 100%; min-block-size: 7rem; max-block-size: 18rem; resize: vertical; }
@supports (field-sizing: content) { .exception-note { field-sizing: content; } }Cost and verification
Growing a control changes layout as text is entered, which is expected but can move nearby controls. Keep the label and error message associated with the field, and test keyboard scrolling after the maximum size is reached. The declaration itself is inexpensive. Unsupported browsers keep the minimum-sized textarea and a resize handle. A content-sized input without a minimum can shrink to a cursor-width sliver, so do not apply the rule to every form control. Measure form completion on small screens before deciding that automatic growth improves the task.
Common Mistakes
- Do not use field-sizing without minimum and maximum limits.
- Do not expect a fixed height to coexist with content growth.
- Do not substitute visual growth for validation or a visible label.
