Inline editing

The problem

Changing one small value — a name, a status, a quantity — sometimes gets a whole navigation to a dedicated edit page for a change that takes one field and one second to type. That round trip costs the reader a page load out and a page load back for a change that didn’t need either. But inline editing isn’t free of cost either: it has to signal that a value is editable at all before anyone clicks it, it has to make committing and cancelling both obvious, and it has to say what happens to the value if the save fails while the reader has already moved on. The failure mode in each direction is different. Skip inline editing where it belongs and every trivial change becomes a small ceremony. Use it where it doesn’t belong — a change with side effects on other data, or one that genuinely needs its own validation and context — and the reader edits a field with no idea what else just changed, or hits a save failure with nowhere to see why.

Inline, or a dedicated view?

Inline editing is for changes with no story to tell. The moment a change needs to explain itself — what else it affects, why a value is rejected — it has outgrown a single field edited in place, and belongs on Form validation’s ground instead.

Vocabulary

Term	Also called	The system uses
Resting	Display mode, view mode, read state	Resting — the value shown as plain text before editing starts
Commit	Save, confirm, apply	Commit — accepting the new value and returning to resting state
Cancel	Discard, revert, undo	Cancel — reverting to the original value with no save attempted

When this applies

The value is a single field, and changing it has no side effects on other data.
The new value needs no validation beyond what a single Input or Select already checks.
The reader benefits from staying on the page they’re already looking at.

When it doesn’t

Situation	Do this instead	Why
The change has side effects on other records, billing, or live routing	A dedicated view	The consequences need their own space to be shown, not a single field with no room to explain them
The value needs real validation — cross-field rules, an async check	Form validation	Inline editing has no room for a page-level error summary or multi-field context
The reader is navigating away with the field still uncommitted	Destructive confirmation	Its own “when it doesn’t” table already covers unsaved edits on navigation — a custom modal on the way out is routinely bypassed by the back button
The action is destructive rather than a simple value change	Destructive confirmation	Deleting or removing something is a different decision than editing a value in place

Structure

Order	Component	Role
1	Resting value	Plain text, with a hover treatment signaling it’s editable — see Constraints
2	Button `icon-only`	Optional explicit edit affordance, for a low-discoverability context — see Constraints
3	Input or Select	The field, in place of the resting value once editing starts
4	Button `icon-only` × 2	Commit and cancel, shown only while editing
5	Tooltip	Labels the icon-only commit/cancel controls — required, since neither carries visible text

Resting:
┌───────────────────────────┐
│  Campaign name             │
│  Q3 Paid Search      ✎     │   ← pencil on hover, not always visible
└───────────────────────────┘

Editing:
┌───────────────────────────────────┐
│  Campaign name                     │
│  [ Q3 Paid Search Retest  ]  ✓  ✕  │   ← commit / cancel, icon-only
└───────────────────────────────────┘

Failed save:
┌───────────────────────────────────┐
│  Campaign name                     │
│  [ Q3 Paid Search Retest  ]  ✓  ✕  │
│  Couldn't save. Try again.         │   ← inline error, edit stays open
└───────────────────────────────────┘

Behavior

State	Behavior
Resting	Value renders as plain text. A hover treatment (and a pencil icon, per Constraints) signals it’s editable
Entering edit mode	Click on the value (or its edit icon) replaces it with an Input or Select, focused and with the current value selected
Committing	`Enter`, or the commit icon. Saves the new value and returns to resting state
Cancelling	`Escape`, or the cancel icon. Reverts to the original value with no save attempted
Clicking outside the field	Treated as commit if the value is valid, cancel if it isn’t — see Constraints
Save succeeds	Returns to resting state showing the new value
Save fails	No component expresses this cleanly — see Known issues and Error handling. This page’s proposal: the field stays open, in its edited state, with the error rendered inline below it

Constraints

ID	Constraint	Rationale
TITAN-INLINE-01	An editable value shows a hover treatment and a pencil icon before it’s clicked. Neither is always visible at rest.	A permanently visible edit icon on every editable value in a dense list adds visual noise to a page’s resting state; a hover cue costs nothing until the reader is already pointing at the value.
TITAN-INLINE-02	A value editable by a single click needs no separate edit icon. A value where an accidental click would be costly, or that shares its space with another click target, gets an explicit icon-only edit button instead.	Click-to-edit is the lower-friction default; an explicit icon is the higher-friction choice reserved for where an accidental edit-mode entry is more than a minor annoyance.
TITAN-INLINE-03	`Enter` commits; `Escape` cancels and reverts to the original value. Both are always available alongside their icon-only equivalents.	A real, well-established convention across text-editing surfaces — a reader does not have to discover it in this one interface.
TITAN-INLINE-04	Commit and cancel controls are icon-only and each carries a Tooltip and an accessible name — never a bare icon with neither.	An icon-only button with no accessible name announces as “button” and nothing else.
TITAN-INLINE-05	A failed save keeps the field open, in its edited, unsaved state, with the error rendered inline. It never silently reverts to the old value.	Reverting on failure discards the reader’s typed correction with no way to recover it — the same reasoning applies to a failed destructive action that closes its dialog on failure.
TITAN-INLINE-06	Clicking outside a field with a valid, changed value commits it. Clicking outside a field with an invalid value cancels it and reverts.	Treating every outside click as cancel silently discards a valid edit the reader believed was saved; treating every outside click as commit can save a value that never passed validation.
TITAN-INLINE-07	Inline editing never surfaces a page-level error summary. A change that needs one belongs on Form validation instead.	A single field editing in place has no page-level chrome to summarize into — needing one is the signal the change has outgrown this pattern.
TITAN-INLINE-08	Navigating away from a page with an uncommitted inline edit follows Destructive confirmation’s existing guidance for unsaved edits, not a rule invented here.	One definition of “leaving with unsaved work,” not two that can disagree.

Content

Element	✅	❌
Failed save, inline	Couldn’t save. Try again.	Error.
Commit icon’s accessible name	Save campaign name	(unlabeled checkmark)
Cancel icon’s accessible name	Cancel edit	(unlabeled ✕)

Accessibility

Entering edit mode moves focus into the field automatically — the reader who clicked or keyboard-activated the value should not have to Tab into it separately.
The commit and cancel controls are reachable by Tab, in addition to their Enter and Escape equivalents — a reader who cannot use keyboard shortcuts still needs a visible path to both.
Each icon-only control’s accessible name states the action and the field it acts on (“Save campaign name,” not “Save”) when a page has more than one inline-editable field, so a screen-reader user moving between rows can tell them apart.
A failed save is announced (a live region, or the error text’s own aria-describedby association to the field) — not only shown visually, per the same reasoning as Input’s error state.

Variations

Variation	When	Change
Table-cell inline edit	The value is one cell in a Table row	Edit mode is scoped to the single cell; commit/cancel icons appear only in that cell, not the whole row
Select-backed inline edit	The value comes from a fixed, enumerable set (a status)	The field becomes a Select instead of an Input; committing happens on selection, with no separate commit icon needed
Always-open edit icon	The value sits in a low-pointer-precision context (touch, dense mobile layout)	The pencil icon is always visible rather than hover-only, since “hover to discover” doesn’t exist on touch

Anti-patterns

Reverting a failed save with no trace. The reader retyped a value, pressed save, and the field quietly snapped back to the old value with no error and no way to tell what happened to their edit. An edit affordance nobody can find. A value that’s editable only via a hover-revealed icon, on a device or in a context where hovering isn’t possible, has no path into edit mode at all. Inline editing a value with real consequences. A field that looks like a quick inline edit but actually changes billing, live routing, or another record’s data gives the reader no indication that clicking away committed something bigger than the one visible field. No keyboard equivalent for commit or cancel. Requiring a mouse click on a tiny icon to save or discard an inline edit, with no Enter or Escape alternative, breaks a convention every reader already expects from editing text anywhere else.

Known issues

ID	Kind	What
TITAN-GAP-22	Open decision	No component in Titan expresses a failed action today — there is a `loading` state and a `disabled` state, and nothing between them for failure. TITAN-INLINE-05’s inline error treatment is this page’s proposal for what fills that gap, not a description of an existing primitive.

Gaps in the current rules

Whether committing one inline edit should be blocked while another inline edit on the same row or page is still open and uncommitted.
What happens to an in-progress inline edit if the underlying record is deleted, or changed by someone else, while the reader is still typing.
Whether a long-running commit needs its own loading treatment on the field, beyond what Behavior currently describes.

Why it works this way

Inline editing borrows Enter and Escape rather than inventing its own commit gesture, because the convention already exists everywhere else text is edited. A reader who has never seen this specific composition still knows what those two keys do the moment the field becomes editable — this pattern is deliberately unoriginal here. The failed-save behavior is argued from the same principle as a failed destructive action, not derived independently. Reverting silently on failure and closing a dialog on failure destroy the same thing — the reader’s belief that their input is still there. Once one of those cases is settled, the other isn’t a new decision; it’s the same decision applied to a different surface. Input and Select, the fields this pattern swaps in during editing. Button and Tooltip, for the icon-only commit, cancel, and edit affordances. Form validation, for a change that has outgrown a single inline field. Destructive confirmation, for leaving a page with an uncommitted edit. TITAN-GAP-22 and Error handling, for the general treatment of a failed action this page’s failed-save behavior works around.

Status

Proposal — first pass, not an audited Invoca screen. No Titan design library or shipped product surface was available while writing this page. What follows is built from general interaction-design practice and from the constraints Foundations and Components already establish — see Status.

​The problem

​Inline, or a dedicated view?

​Vocabulary

​When this applies

​When it doesn’t

​Structure

​Behavior

​Constraints

​Content

​Accessibility

​Variations

​Anti-patterns

​Known issues

​Gaps in the current rules

​Why it works this way

​Related

​Status

The problem

Inline, or a dedicated view?

Vocabulary

When this applies

When it doesn’t

Structure

Behavior

Constraints

Content

Accessibility

Variations

Anti-patterns

Known issues

Gaps in the current rules

Why it works this way

Related

Status