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 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.