A framework-held field reformats text as it is typed, and the caret jumps to the end — why?

## Why the caret moves at all A host text field maintains a **selection** — an anchor and a focus offset into its current text. Ordinary typing moves that selection by one, in step with the text, because the host is editing its own buffer. A framework-held field breaks that continuity: the authority is state, so after every input the framework writes the authoritative string onto the element. When the string is unchanged from what the element already holds, most frameworks skip the write and the selection is untouched — which is why an ordinary framework-held field feels normal. When formatting has changed the string, the write happens, the element's text is replaced as a unit, and the offset the selection referred to no longer describes the same position. Hosts typically resolve that by putting the caret after the new text. So the jump is not caused by the mask arithmetic, or by focus loss, or by the element being re-created. It is caused by a **wholesale value replacement on a focused field**. ## What one formatting keystroke actually does 1. The user types a digit in the middle of an already-formatted string. 2. The host inserts it, and its selection sits just after the inserted digit. 3. The handler receives the text, runs the mask, and writes a differently formatted string into state — perhaps with a separator now added or removed before the caret. 4. The framework renders, the string differs from the element's text, and the element's value is replaced. 5. The host has nothing to anchor the old selection to, so the caret lands at the end. Step 3 is the reason the string differs; step 4 is the reason the caret moves. Both are consequences of the framework owning the value. ## Restoring the caret correctly Counting offsets in the formatted string does not survive masking, because the mask adds and removes characters before the caret. Count in the characters the user actually cares about instead: 1. Before the write, take the caret offset in the pre-edit text and count how many **significant** characters precede it — digits, for a card or phone mask — ignoring separators. 2. Apply the mask and write the new authoritative string. 3. After the element has been updated with that string — that is, in the phase your framework gives you for reading or touching the host after a commit — walk the formatted string until you have passed the same number of significant characters, and set the selection to that offset. | Approach | Survives inserting in the middle | Survives deleting a separator | Notes | |---|---|---|---| | Restore the raw offset | no | no | Off by however many separators the mask changed | | Restore offset plus length difference | sometimes | no | Breaks when the mask changes characters before the caret | | Count significant characters | yes | yes | Stable across reformatting; the usual approach | | Format on blur only | yes | yes | No repair needed; the field is unformatted while editing | Deletion needs one extra decision: when the user backspaces over a separator, decide whether that removes the separator alone (and the mask immediately puts it back, so the key appears to do nothing) or the significant character before it. Pick one and implement it deliberately; the version that appears to do nothing is the one users report as broken. ## Cheaper strategies that avoid the repair - **Keep the raw value as the authority** and render the formatted version somewhere else — beside the field, or in a read-only display. Nothing replaces the element's text while it has focus. - **Format on blur.** The user edits raw text; the mask applies once when they leave. One value replacement, on an unfocused field, where the caret does not matter. - **Restrict the mask to appending.** A field that only ever formats at the end has no middle edits to preserve, which is why grouping applied while typing at the end so often ships without anyone noticing the problem. - **Do not mask at all** where the format is presentational; accept any separators and normalise at submit. ## Judgment Caret preservation is real work with real edge cases — selection ranges rather than a single point, paste, deletion across a separator, and an input method that composes several keystrokes into one character. A masked field is therefore a component you write once, test properly and reuse, not a handler copied into each form. If a form has one masked field and no live consumer of its value, the honest recommendation is often to stop owning that value per keystroke: the cheapest correct masked field is frequently the one that formats when the user is done.