Inspect the working example
This textarea begins with Bring the source file. The original text inside the element defines its default. After you replace it with Revised note., the current value changes while the original default remains available.
| Case | Input or inspection | Result and meaning |
|---|---|---|
| Initial value | Read value | Bring the source file. |
| Initial default | Read defaultValue | Bring the source file. |
| After editing | Replace current text with Revised note. | value=Revised note.; defaultValue remains Bring the source file. |
Follow the browser mechanism
A textarea’s initial/default value comes from its child text, not a value attribute. Once the user edits the current value, that dirty value is separate from the default text. This example changes only a local control; it does not save the note or synchronize a draft.
A value attribute does not initialize textarea
This source leaves the element empty and attempts to supply its text through value. That attribute is not the textarea initialization mechanism.
<label for="notes">Workshop notes</label><textarea id="notes" rows="3" value="Bring the source file."></textarea>Both value and defaultValue are empty in the counterexample, even though the source contains a value attribute.
Try the repair
The current field says Revised note. while defaultValue still contains the original instruction. Has editing changed the original default?
Show the worked answer
No. It changed the current value only. If the intended default must change, update that default separately and define what should happen to an already edited field.
- Compare value and defaultValue before and after typing.
- Keep the visible label associated with the textarea ID.