Modal Dialog Anchored to a Trigger Element

When a Dialog Wants an Anchor

Most modal dialogs are centered in the viewport. But a small subset — confirmation prompts, quick-edit forms, "are you sure?" panels — read more naturally when they appear right next to the element they're acting on. Anchor positioning lets you do that with the native <dialog> element.

<button class="delete-btn" id="delete-1">Delete</button>
<dialog class="confirm-dialog" id="confirm-1">
  <p>Delete this item?</p>
  <menu>
    <button autofocus value="cancel">Cancel</button>
    <button value="confirm">Confirm</button>
  </menu>
</dialog>

#delete-1 {
  anchor-name: --delete-1;
}

#confirm-1 {
  position: absolute;
  position-anchor: --delete-1;
  position-area: bottom-end;
  margin-top: 8px;

  /* Reset some default <dialog> centering */
  inset: auto;
  margin: 0;

  position-try-fallbacks: flip-block, flip-block flip-inline;
}

<dialog> quirks

The native <dialog> element has built-in centering when opened with .showModal(). To anchor it instead, you need to:

1. Reset inset: auto and margin: 0 to clear the dialog's default inset: 0; margin: auto centering.
2. Open the dialog with .show() (non-modal) or .showModal() (modal). Both work with anchor positioning.

Modal vs non-modal

.showModal() adds a backdrop and traps focus. .show() does neither. For "quick-edit" anchored dialogs, .show() is usually right — the user shouldn't have to dismiss a backdrop to keep working. For destructive confirmations ("Delete this item?"), .showModal() adds the proper friction.

Avoid for global dialogs

Centered modal dialogs (account settings, full-page wizards) don't need anchor positioning. Save this pattern for the small inline confirmations and edits.