--- title: Inline Editing slug: inline-editing kind: pattern summary: Change a value where it is displayed, without leaving the screen or opening a form — the shortest possible distance between noticing something is wrong and fixing it. problem: >- Correcting one field costs a round trip: open the record, find the edit form, locate the field among thirty, change it, save, and come back to where you were. The correction takes two seconds and the journey takes twenty, so small errors do not get fixed. family: [edit, scan] data_shape: [record, tabular, collection] principles: [friction, minimize-distance, consistency] interaction: [inline-editing, direct-manipulation] density: high complexity: medium status: stable visibility: public use_when: - Fields are independently valid, so changing one alone cannot corrupt the record. - People correct values while reviewing a list, rather than filling a record in one sitting. - The value's context — the row, the neighbours, the total — is part of judging what it should be. avoid_when: - Several fields must change together to stay consistent. That is a form and a transaction. - Changing the value fires a side effect someone should confirm first. - The field needs substantial guidance, examples or validation explanation to fill in correctly. alternatives: - slug: autosave when: The whole record is composed in place over a long session, not corrected field by field. - slug: master-detail-drawer when: People need the whole record to make the change, not just the one value. ask_leo: | Make these values editable in place. - Show the value as text, and make it obviously editable on hover and on keyboard focus — a subtle field outline. Do not render permanent input boxes for every value; that turns a readable list into a form. - Clicking, or pressing Enter on a focused value, switches that one value into an input with the text selected. - Commit on blur and on Enter. Escape cancels and restores the original value. - Keep the element exactly the same size in both states, so nothing on the screen moves when editing starts or ends. - After committing, keep focus where the person put it. If the row re-renders, restore focus to the same cell — losing focus mid-pass is what makes inline editing feel broken. - Show a per-value save state, and on failure keep what they typed, show the error next to that value, and leave it in edit mode. - Validate the single value only. Do not block the save because a different field elsewhere on the record is incomplete. - Support Tab to move to the next editable value so a whole column can be corrected without the mouse. related: - title: High-Quality Inline-Editable Table url: /cookbook/inline-editable-table summary: The Rails, Turbo and Stimulus implementation of this pattern. - title: Focus Jumping in Inline-Editable Tables url: /cookbook/focus-restoration-after-row-replace summary: The specific bug this pattern lives or dies by, and how to fix it. - title: One consistent pattern url: /patterns/consistency summary: Editing where the value lives removes the second mental model entirely. --- ## Anatomy ``` read state hover / focus editing ────────── ───────────── ─────── $8,400 ┌─────────┐ ┌─────────┐ │ $8,400 │ │ 8400.00 │ ↵ commit └─────────┘ └─────────┘ esc cancel same size same size ``` The rules are unusually strict, because inline editing fails on small details: - **Same box in every state.** If the input is a different size from the text, the whole row shifts when editing begins and the page flickers as someone tabs across it. - **Enter commits, Escape cancels, blur commits.** These are the conventions people already have. Deviating costs more than any gain. - **Focus survives the save.** This is the make-or-break detail. A row that re-renders after commit and drops focus makes a keyboard pass through a column impossible. - **Errors stay next to the value** and keep the typed text. ## Why it works It collapses the distance between noticing and fixing to nearly zero. That matters more than the seconds saved: when correcting a value is expensive, people batch corrections, then forget them, and the data quietly rots. Cheap correction is what keeps a dataset honest. It also removes a whole mental model. With a separate edit form, one object has two representations and the person maintains a mapping between them. Editing in place means the thing you are looking at *is* the thing you are changing — the [consistency](/patterns/consistency) principle at its most literal. Keeping the surrounding context visible is the third gain. Judging whether an amount is right often depends on the neighbouring rows, the total, or the last invoice. A form throws all of that away at the moment you need it. ## The focus problem Almost every failed implementation fails the same way. The value is saved, the server returns updated markup, the row is replaced, and the focused element no longer exists — so focus falls back to the document body. The person tabs expecting the next cell and lands at the top of the page. Treat focus restoration as part of the feature, not a polish item. If the implementation replaces DOM nodes on save, it must find the equivalent node afterwards and restore focus and selection to it. ## Getting it wrong - **A grid of permanent input boxes.** Technically inline, but it has turned a scannable list into a form and destroyed its readability. - **No affordance.** If nothing indicates editability, only people who were told will ever try clicking. - **Layout shift on edit.** Rows jump, and a keyboard pass becomes seasickness. - **Whole-record validation.** Blocking a name change because a phone number elsewhere is malformed makes the fast path slower than the form. - **Silent failure.** The value snaps back to its old text with no message, and the person believes they saved. - **Inline editing something with side effects**, where a mistyped keystroke emails a customer. ## Exemplars **Airtable** treats the grid as the primary editing surface and gets every detail of keyboard traversal right — which is why it feels like a spreadsheet rather than a web form. **Linear** applies it selectively: title and properties are editable in place, while anything that notifies people stays an explicit action. That selectivity is the judgment worth copying. **Google Sheets** is the reference for the state machine — read, selected, editing are three distinct visual states, and every keyboard convention people already have works exactly as expected. The extractable rule: **inline editing is a keyboard feature that happens to be clickable.** If a person cannot correct a whole column without touching the mouse, it has not been finished.