In HTML, how do you give a <textarea> an initial value, and what do its rows and cols attributes actually control?

## Content is the value `<input>` carries its default in a `value` attribute. `<textarea>` cannot: its value is multi-line text, and attribute values are a poor place for line breaks. So the element's *children* are the value: ```html <label for="bio">Short bio</label> <textarea id="bio" name="bio" rows="6" cols="40">Frontend engineer.</textarea> ``` This is the element's **default value** — the same role `value` plays on an input. It is what the control shows on load and what a form reset restores. Once the user types, the current value lives only in the DOM; the markup does not change. Serialising the DOM back to a string therefore does not capture what the user typed, which is a classic surprise when someone tries to "save the HTML". ## The parser rules that bite `<textarea>` is a *raw text* element (along with `<title>`). Two consequences: 1. **Markup inside is not markup.** A `<b>` tag written inside a textarea shows up as the literal characters `<b>`, not as bold text. Only character references such as `&amp;` are decoded. 2. **The closing tag cannot appear in the content.** The first closing textarea tag ends the element. If your server templates user content into a textarea, that same string appearing in the content would terminate it early and let the rest be parsed as markup — so escape at least `<` and `&` when interpolating. And the rule everyone hits once: **a newline immediately after the opening tag is stripped** by the parser. That is why this is safe — ```html <textarea> Hello</textarea> ``` — it yields exactly `Hello`. But this is not: ```html <textarea> Hello </textarea> ``` Only the *first* newline is dropped; the two indent spaces, the trailing newline and any further whitespace are all part of the value. Pretty-printed templates are the usual source of a textarea that mysteriously starts with blank space. Put the content flush against the tags, or emit it from a template expression. ## rows and cols `rows` is the number of text lines visible without scrolling; the default is 2. `cols` is the visible width measured in average character widths; the default is 20. Both are *initial sizing* only — they impose no limit whatsoever on how much the user may type, and CSS `width`/`height` override them. So why set them? Because they render before any stylesheet applies, they give a sensible box if CSS fails, and `rows` is the honest way to express "this field expects about six lines" — a size hint the user reads as an expectation of how much to write. Setting `cols` on a fluid layout is usually pointless since a width rule will win. Limiting the *amount* of text is a separate concern handled by `maxlength`/`minlength`, not by `rows`/`cols`. ## wrap, and what actually gets submitted `wrap` has two values. The default, `wrap="soft"`, means the text wraps visually but is submitted exactly as typed — no line breaks are inserted. `wrap="hard"` inserts a real line break at each wrap point in the submitted value, and requires `cols` to be specified so the browser knows where the wraps fall. `hard` is rare and only makes sense for fixed-width output such as plain-text email bodies. One more normalisation to know: line breaks in the value read from the DOM are `\n`, but on submission the value is normalised to CRLF (`\r\n`) pairs. Code that counts characters client-side and server-side can disagree by one byte per line break because of this. ## Resizing and the other attributes Browsers make textareas user-resizable by default; that behaviour is controlled by CSS, not markup. The genuinely useful markup attributes beyond the above are `placeholder` (a hint, never a substitute for a label), `readonly` (submitted but not editable), `disabled` (not editable and *not* submitted), and `spellcheck`. Auto-growing a textarea as the user types has no markup solution and requires script.