Editable Input, Composition, and Document Model

Working case

Reviewer 29 writes a case note containing a heading and a paragraph. An IME begins composing a place name. The editor keeps the provisional text visible without converting each keystroke into a committed document transaction. When composition ends, it normalizes the resulting block and records one logical edit. A spell correction later changes a word through a browser path the editor did not cancel in beforeinput; input reconciliation updates the model. The server sees a versioned, allowed document structure, not arbitrary DOM markup copied from the browser.

Implementation boundary

function mayNormalize(composing, inputCommitted) {
  return !composing && inputCommitted;
}
console.log(mayNormalize(true, true));
// Output: false

Choose an explicit schema for blocks and marks. Give each block a stable ID and define allowed operations: insert text, split paragraph, apply emphasis, remove block. Observe beforeinput where useful, but reconcile on input because the former may be absent or non-cancelable. Track composition start and end and defer destructive normalization until the session settles. Validate incoming document transactions and limit size and nesting. Serialize the model to a safe representation for storage; render it through a controlled component or maintained sanitization boundary. Test multiple input methods and mobile keyboards.

Cost and boundaries

A model transform can be O(length of the affected block) rather than O(entire document) if operations are scoped. Full DOM serialization on every keypress can become O(n) and move the caret unexpectedly. Composition handling adds state and test surface but prevents lost characters. A custom rich editor is costly to maintain across browsers; use a plain textarea if headings and marks are not a real product need. Measure typing latency, reconciliation frequency, document size, and input methods used in the target audience.

Failure trace

The editor cancels every beforeinput event, including an IME path it does not understand, and reviewer 29 cannot enter the place name. Another build trusts the DOM after a spell correction and saves unsupported nested markup. Test composition, paste, drag, autocorrect, mobile dictation, undo, empty document, 47 large paragraphs, and focus after a model update. Confirm the saved representation conforms to the schema and the visible text exactly matches the user’s committed input.

Verification

• IME composition survives intermediate updates.
• Input reconciliation covers uncancelable edits.
• Saved blocks obey an explicit schema.

Practice drill

Define heading and paragraph blocks with stable IDs. Feed an insert-text transaction, a composition sequence, and a spell correction into the editor. Compare the model with the visible surface after each committed step. Try to insert an unsupported element and verify it is normalized or rejected without losing surrounding text. Run the same note in a plain textarea to decide whether the added editor complexity serves an actual task.

Decision note

Treat the browser as an input source and keep one validated document model as the saved authority.

Common Mistakes

• Assuming every beforeinput is cancelable.
• Serializing arbitrary live DOM as the document.
• Rebuilding the entire editable surface on each keystroke.

Connected lessons

Build Project: versioned case note editor and review Web Development: graphics and editor decisions quiz; follow Rich Document Editing and Safe Content; Selection Bookmarks and Transaction Mapping; Paste Import, Sanitization, and Link Policy; Undo History, Autosave, and Revision Conflicts; Forms and Data Entry Workflows; DOM Sinks and Trusted Content.