Actions

Purpose

Action patterns define how buttons are grouped and arranged for recurring UI contexts. They answer where to place actions, what emphasis to assign each one, and how many actions are appropriate per context.

These patterns use the button primitive. See Button for variant and state rules.

Form footer

Used at the bottom of forms, settings panels, and multi-step flows.

<div class="border-t border-dark/12 pt-4 flex justify-end gap-3">
<Button variant="outlined">Cancel</Button>
<Button variant="primary">Save changes</Button>
</div>

Composition:

• Primary action on the right (in left-to-right, desktop workflows)
• Outlined or ghost partner action beside it (usually Cancel)

Rules:

• Avoid placing multiple prominent actions side by side
• Do not use primary + primary — it creates ambiguity about which action matters
• Use full-width buttons only on narrow mobile layouts or simple single-action forms

Hierarchy rules

Across all action patterns, three rules apply:

1. One primary per local area — do not stack multiple high-emphasis buttons
2. Supporting actions step down — outlined where the action still needs a visible affordance, ghost where a border would only add noise
3. Danger is reserved — use it only in confirmation contexts, never for normal priority

Modal footer

Used inside confirmation, edit, and detail modals.

<div class="flex justify-end gap-3">
<Button variant="outlined">Cancel</Button>
<Button variant="primary">Save</Button>
</div>

<div class="flex justify-end gap-3">
<Button variant="outlined">Cancel</Button>
<Button variant="danger">Delete</Button>
</div>

Composition:

• Primary button confirms the modal’s main action
• Outlined or ghost cancels without action
• Danger used only when confirming a destructive action

Rules:

• The confirm and cancel actions should be close together, typically right-aligned
• Avoid a third competing action in the modal footer — move it elsewhere or reconsider the modal structure

Page header actions

Used in the header of a page or section, next to the page title.

<header class="flex flex-wrap items-center justify-between gap-4">
<h1 class="text-h4 m-0">Campaigns</h1>
<div class="flex gap-2">
  <Button variant="ghost">Export</Button>
  <Button variant="outlined">Edit</Button>
  <Button variant="primary">Publish</Button>
</div>
</header>

Composition:

• One primary action maximum
• Outlined actions grouped near it
• Ghost actions only when density is high and screen space is limited

Rules:

• Do not place multiple primary buttons in a single page header
• Keep the action count low — three or fewer before moving extras behind a menu or overflow control
• The primary action should represent the most important thing a user can do on the page
• The title is a heading in the document outline; the demo above uses a <p class="text-h4"> only because a preview is not part of this page’s outline

Inline actions

Used inside tables, lists, cards, and dense content areas.

<li class="flex items-center justify-between gap-4 px-4 py-3">
<span class="text-p">Q3-revenue.csv</span>
<div class="flex gap-1">
  <Button variant="ghost" size="sm">Edit</Button>
  <Button variant="ghost" size="sm">Remove</Button>
</div>
</li>

Composition:

• Ghost buttons only, or outlined where the affordance has to be visible at rest
• Icon-only buttons where space is constrained and actions are common

Rules:

• Avoid primary buttons inside dense content unless the action is truly dominant to everything else on the page
• Keep inline action labels short: Edit, Remove, View
• Icon-only inline actions must have accessible labels

Destructive confirmation

Used when a user initiates an action that cannot be undone and requires explicit confirmation.

<div>
<p class="text-p">This will permanently delete <strong>Northwind</strong> and all of its data.</p>
<div class="flex justify-end gap-3">
  <Button variant="outlined" autofocus>Cancel</Button>
  <Button variant="danger">Delete project</Button>
</div>
</div>

Composition:

• Danger button confirms the destructive action
• Outlined or ghost button cancels
• Supporting text near the buttons explains the consequence

Rules:

• The cancel action must always be present and easy to reach
• The danger button should never be the default focused action on load — place focus on cancel or another non-destructive control
• Supporting text should name what will be lost or affected — “its 14 campaigns” is a warning; “this cannot be undone” on its own is not

Grouped actions / segmented control

Used when multiple related views or modes are available and only one can be active at a time.

<div role="group" aria-label="View" class="inline-flex gap-1 rounded-lg border border-dark/12 bg-light p-1">
<Button variant="ghost" size="sm" aria-pressed="true"
        class="aria-pressed:bg-white aria-pressed:text-dark aria-pressed:shadow-sm">Grid</Button>
<Button variant="ghost" size="sm" aria-pressed="false"
        class="aria-pressed:bg-white aria-pressed:text-dark aria-pressed:shadow-sm">List</Button>
</div>

Composition:

• A set of toggle buttons rendered as a unified group
• One option selected at all times (radio-like behavior)

Use cases:

• Grid / List view
• Day / Week / Month
• Bold / Italic / Underline

Rules:

• Selection lives on aria-pressed, which is both the semantics and the styling hook — there is no active class to keep in sync
• Keep the group to 5 or fewer options — more than that becomes a different UI pattern (tabs or a select)
• All options in the group must be roughly equal in weight and importance
• Do not mix grouped toggle buttons with standalone primary or outlined buttons in the same action bar without clear visual separation