18 Tailwind CSS Forms

The contact form (demo 01) grows its comment box with the CSS field-sizing: content property — no scroll-height JavaScript, no rows juggling. In Tailwind v4 you apply it as an arbitrary utility, [field-sizing:content], on the <textarea>. The element then sizes itself to the wrapped text and reflows on every keystroke. Pair it with a min-h-24 so an empty field still has a comfortable tap target, and a max-h-64 plus overflow-auto so a pasted essay scrolls instead of pushing the submit button off-screen. The common bug is forgetting the min height: an empty field-sizing textarea collapses to a single line and reads as broken. Support is modern Chromium and Firefox; Safari falls back to the fixed rows value, which degrades cleanly rather than breaking the layout.

Demo 01 pairs the auto-growing textarea with a live character count. That part is JavaScript: an input listener reads the field's value.length and writes it into a counter node. Bind to input, not keyup, so paste, autofill and drag-drop all update the count — keyup misses every one of those. For accessibility, don't signal the limit with colour alone, since screen-reader users can't see it: put the counter in an aria-live region set to polite so it announces as the user types, and phrase it as '12 characters left'. If you enforce a hard cap, set maxlength on the <textarea> itself so the browser blocks overflow even when your script hasn't loaded. Announce only when the remaining count crosses a threshold, not on every keystroke, or the live region turns into constant noise that drowns out everything else on the page.

The registration form (demo 02) scores password strength in JavaScript, because real checks — length, character classes, rejecting common passwords — are logic a stylesheet can't run. The script scores the value and sets a width and colour on a meter bar. Render that bar with a native <meter> or <progress> element rather than a bare <div>, or at least add role and aria-valuenow, so assistive tech announces 'strength: strong' instead of nothing. The usual bug is treating the meter as validation: a green bar is advisory, so never gate submit on it alone — enforce your real floor with minlength and server-side rules. Run the check on input and keep it cheap; don't ship a 10,000-entry common-password dictionary to the client just to colour a bar. The meter guides the user, your backend decides what's actually acceptable.

Demos 03 and 05 adapt to the width of their slot, not the browser window, using container queries. You mark the wrapper as a query container — in Tailwind v4 that is the @container utility — then style children with container variants like @md:flex-row. The newsletter form (demo 05) lays its input and button side by side when the column is wide and stacks them when it's narrow, so the same markup works in a footer, a sidebar and a hero without media queries. The common bug is forgetting to declare the container: an @md: variant with no @container ancestor silently never matches, and the form looks like it ignores your breakpoints entirely. Remember the query measures the container's width, so a form dropped into a 400px sidebar stays stacked even on a 4K monitor — which is exactly the behaviour you want from a reusable component.

The job application (demo 08) and insurance quote (demo 12) are multi-step wizards driven by CSS state, not a framework. A set of hidden radio inputs — one per step — acts as the state machine: :checked combined with the sibling selector reveals the matching panel and hides the others, and the step controls are <label> elements pointing at those radios. No router, no component library. The accessibility catch: hiding a panel with hidden or display:none correctly pulls it out of the tab order, but if you only fade it with opacity the fields stay focusable and keyboard users tab into an invisible step. Give each step a heading and move focus to it on advance. When not to use it: skip this pattern when steps must validate server-side before proceeding, or when progress has to survive a reload — at that point a real state container earns its weight.

The shipping form (demo 04) ships the correct autocomplete tokens so browsers and password managers fill it in one tap. Use the granular address tokens — address-line1, address-line2, postal-code, country-name — plus name, email and tel on the matching inputs. The single most common bug is a blanket autocomplete='on' or a mismatched token: the browser then offers nothing, or drops the city into the street field. Each token must sit on the input whose type and label agree with it. For a billing address on the same page as shipping, prefix with a section token like shipping or billing so the two forms don't fight over the same saved values. This isn't cosmetic — correct autofill is one of the largest real conversion wins on any checkout, and it costs one attribute per field.

The mortgage calculator (demo 16) links a range slider and a number input to the same value — drag the slider and the number updates, type a figure and the thumb moves. That two-way binding is a small script: an input listener on each control writes the other's value and recomputes the estimate. Bind both to input, not change, so the figure tracks live during a drag instead of jumping only on release. Keep the number field as the real labelled control and give the bare slider an aria-label, because dragging a range is hard for motor-impaired and screen-reader users — the number input is their path in. Watch the clamp bug: validate the typed number against the slider's min and max before echoing it back, or a user types 9,999,999, the thumb pins silently to the end, and your math quietly uses the raw figure instead.

Several forms here colour fields with the native CSS pseudo-classes :valid, :invalid, :required and :placeholder-shown — in Tailwind v4 those are the valid:, invalid: and required: variants. The browser evaluates them from the input's type, required and pattern, so an email field turns red the moment the value isn't a valid address, with no script. The classic bug is an angry red border on an empty field the user hasn't touched yet: guard it with :not(:placeholder-shown), or a :user-invalid variant where supported, so errors appear only after input. Never signal the error with colour alone — pair it with an icon or a text message tied to the field via aria-describedby, and keep the real gate on the server, because client-side validation is a convenience for the user, not a security boundary.