HTML textarea wrap: distinguish display wrapping from submitted line breaks

When it earns its place

An incident narrative should preserve the editor's intentional line breaks, so soft wrapping is appropriate. A separate fixed-width export note feeds a legacy print system that expects short lines, making hard wrapping a deliberate integration contract. Keep these fields distinct. A CSS width can change how the control looks without changing the form value; hard wrapping changes that value. If exact bytes matter, test the browser-to-server payload rather than inferring it from the visual line breaks.

<form action="/incidents/I-47/notes" method="post">
  <label for="incident-narrative">Incident narrative</label>
  <textarea id="incident-narrative" name="narrative" rows="7" wrap="soft" required></textarea>
  <label for="print-note">Fixed-width print note</label>
  <textarea id="print-note" name="print_note" rows="4" cols="36" wrap="hard"></textarea>
  <button type="submit">Save notes</button>
</form>

Browser boundary

Hard wrapping requires cols and its line-breaking details are browser-defined. The server should normalize and validate text for the receiving system rather than relying on a particular visual wrap location.

Cost and maintenance

Soft wrapping has no extra processing cost. Hard wrapping can alter stored text and diffs; use it only when the downstream format needs inserted line breaks, not merely to make an editor narrower.

Common Mistakes

• Do not use wrap=hard just to control on-screen width.
• Do not assume CSS line wrapping changes submitted text.
• Do not compare unnormalized line endings across systems.

Connected lessons

• HTML select and textarea: preserve meaningful values and editable text
• HTML dirname: submit text direction beside the user's words
• HTML constraint validation: improve feedback without trusting the browser

Form and type styling

• CSS field-sizing: let a note grow within firm limits