Skip to main content
astrocraft-ui/ components · 101

Context Menu

Free · MIT

Headless, accessible, and styled entirely through the attribute surface below — bring your own CSS system, or start from the reference theme.

Install

Without a flag you get no styling at all — plain HTML carrying the attribute surface below. --theme copies the same theme in two dialects;--bridge lumos re-points either one onto Lumos for Astro's tokens (it needs a theme to re-point, and Lumos itself, already in your project).

Unstyled — behavior only, you write the CSS

Install command
npx astrocraft-ui add overlays/context-menu

Plain-CSS theme — no build step

Install command
npx astrocraft-ui add overlays/context-menu --theme css

Tailwind theme — needs Tailwind v4

Install command
npx astrocraft-ui add overlays/context-menu --theme tailwind

Plain-CSS theme, re-pointed onto Lumos tokens

Install command
npx astrocraft-ui add overlays/context-menu --theme css --bridge lumos

Tailwind theme, re-pointed onto Lumos tokens

Install command
npx astrocraft-ui add overlays/context-menu --theme tailwind --bridge lumos

Live demo

ContextMenu & menu parts

Right-click inside the box. Hold Shift while you do and you get the browser's own menu back instead. Focus the box and press the context-menu key and it opens anchored to the box, not at the corner of the screen. The checkbox and radio items keep the menu open on purpose, and report through a plain change event.

Right-click anywhere in this region

Nothing chosen yet.

Attribute surface

With no class-merging machinery, these attributes are the whole extension point. State is a data-attribute or a native attribute; visibility is the hiddenattribute. Generated from source by pnpm slots.

ComponentSlotsVariantsRuntime stateNative state
`ContextMenu.astro``context-menu`———
`ContextMenuContent.astro``context-menu-content``data-side`: `bottom` · `top` · `left` · `right`
`data-align`: `start` · `center` · `end`
——
`ContextMenuItem.astro``context-menu-item`———
`ContextMenuTrigger.astro``context-menu-trigger`———

Source

What the command copies — 5 files, alias-free so the copy lands standing alone. This is the whole component; there is nothing else.

src/components/ui/overlays/context-menu/ContextMenu.astro
---
// src/components/ui/overlays/context-menu/ContextMenu.astro — headless primitive (see ../../README.md).
// A right-click menu over a region of the page. Compose ContextMenuTrigger / ContextMenuContent /
// ContextMenuItem (and the Menu parts — MenuGroup, MenuSeparator, MenuCheckboxItem, MenuRadioItem).
//
// Three things earn this a file, and all three are easy to get wrong:
//   • It anchors to the POINTER, not to an element. `_anchor` takes a zero-size rect at the click
//     and flips the menu near an edge exactly as it would for a trigger.
//   • It is reachable from the keyboard. The ContextMenu key and Shift+F10 fire a real `contextmenu`
//     event, but with no pointer position — so the menu anchors to the trigger instead, rather than
//     opening in the corner of the screen.
//   • It gives the browser's own menu back when the user holds Shift, which is how every
//     custom-menu-bearing site the platform authors had in mind is expected to behave. Swallowing
//     it unconditionally takes away view-source, open-in-new-tab and the spell checker.
// Roving, checked items and closing on activate come from the shared `_menu` controller.
import type { HTMLAttributes } from "astro/types";

type Props = HTMLAttributes<"div">;

const { class: className, ...rest } = Astro.props;
---

<div class={className} data-slot="context-menu" {...rest}>
  <slot />
</div>

<script>
  import "../../_menu";

  import { anchorTo, place, pointRect } from "../../_anchor";
  import { onReadyOnce } from "../../_once";

  function wire(root: HTMLElement) {
    const trigger = root.querySelector<HTMLElement>('[data-slot="context-menu-trigger"]');
    const panel = root.querySelector<HTMLElement>('[data-slot="context-menu-content"]');
    if (!trigger || !panel) return;

    trigger.addEventListener("contextmenu", (event) => {
      if (event.shiftKey) return; // the escape hatch back to the browser's own menu
      event.preventDefault();

      // Keyboard invocation reports no usable position — Firefox has historically sent 0,0 — so the
      // menu anchors to the trigger. A genuine click at the very top-left corner lands here too,
      // where anchoring to the trigger is just as sensible an answer.
      const fromPointer = event.clientX !== 0 || event.clientY !== 0;
      anchorTo(panel, () =>
        fromPointer ? pointRect(event.clientX, event.clientY) : trigger.getBoundingClientRect(),
      );

      // Already open (a second right-click elsewhere in the region): move it rather than re-show it,
      // which would throw and would lose the menu's place in the top layer.
      if (panel.matches(":popover-open")) place(panel);
      else panel.showPopover();
    });
  }

  onReadyOnce('[data-slot="context-menu"]', wire);
</script>
src/components/ui/overlays/context-menu/ContextMenuContent.astro
---
// src/components/ui/overlays/context-menu/ContextMenuContent.astro — ContextMenu part (see ../../README.md).
// Top-layer `role="menu"` on the native Popover API: native light-dismiss, native Escape, native
// focus return. `data-anchor` opts it into the shared `_anchor` controller, which the ContextMenu
// script points at the pointer. `id` is required — the trigger's `aria-owns` names it.
//
// `align="start"` and `side="bottom"` are the defaults because that is where a pointer-anchored menu
// belongs: down and to the right of the cursor, flipping near an edge.
import "../../../../styles/structure.css";

import type { HTMLAttributes } from "astro/types";

type Props = HTMLAttributes<"div"> & {
  id: string;
  side?: "bottom" | "top" | "left" | "right";
  align?: "start" | "center" | "end";
  offset?: number;
};

const { side = "bottom", align = "start", offset, class: className, ...rest } = Astro.props;
---

<div
  popover="auto"
  role="menu"
  data-slot="context-menu-content"
  data-anchor
  data-side={side}
  data-align={align}
  data-offset={offset}
  class={className}
  {...rest}
>
  <slot />
</div>
src/components/ui/overlays/context-menu/ContextMenuItem.astro
---
// src/components/ui/overlays/context-menu/ContextMenuItem.astro — ContextMenu part (see ../../README.md).
// A command in the menu; renders an <a> when `href` is set, a <button> otherwise. `role="menuitem"`
// is what the shared `_menu` controller roves over and what makes activating it close the menu —
// there is no slot name to keep in sync, because the role IS the contract.
import type { HTMLAttributes } from "astro/types";

type Props = HTMLAttributes<"button"> & { href?: string };

const { href, class: className, ...rest } = Astro.props;
const Tag = href ? "a" : "button";
---

<Tag
  href={href}
  type={href ? undefined : "button"}
  role="menuitem"
  data-slot="context-menu-item"
  class={className}
  {...rest}
>
  <slot />
</Tag>
src/components/ui/overlays/context-menu/ContextMenuTrigger.astro
---
// src/components/ui/overlays/context-menu/ContextMenuTrigger.astro — ContextMenu part (see ../../README.md).
// The region that owns the custom menu. `for` names the ContextMenuContent's `id` and is rendered as
// `aria-owns`, so the relationship is in the accessibility tree even though the menu lives in the
// top layer and is nowhere near this element in the DOM order a screen reader walks.
//
// `tabindex="0"` is not decoration: a menu that can only be opened with a right-click is a menu a
// keyboard user cannot reach. Focusing the region is what makes Shift+F10 and the ContextMenu key
// work, and the ContextMenu script anchors to this element when they do.
// jsx-a11y guards against tab stops on inert content. This div is not inert: it OWNS a menu, which
// is what aria-haspopup says — and the ContextMenu key and Shift+F10 fire at whatever currently has
// focus, so with no tab stop the menu is mouse-only. Deleting the tabindex deletes keyboard access.
/* eslint-disable astro/jsx-a11y/no-noninteractive-tabindex */
import type { HTMLAttributes } from "astro/types";

type Props = HTMLAttributes<"div"> & { for: string };

const { for: target, class: className, ...rest } = Astro.props;
---

{
  /* The rule guards against tab stops on inert content. This div is not inert: it OWNS a menu, which
    is why it carries aria-haspopup — and the ContextMenu key and Shift+F10 fire at whatever has
    focus, so without a tab stop the menu is mouse-only. Removing this removes keyboard access. */
}
{}
<div
  tabindex="0"
  aria-owns={target}
  aria-haspopup="menu"
  data-slot="context-menu-trigger"
  class={className}
  {...rest}
>
  <slot />
</div>
src/components/ui/overlays/context-menu/index.ts
import ContextMenu from "./ContextMenu.astro";
import ContextMenuContent from "./ContextMenuContent.astro";
import ContextMenuItem from "./ContextMenuItem.astro";
import ContextMenuTrigger from "./ContextMenuTrigger.astro";

export { ContextMenu, ContextMenuContent, ContextMenuItem, ContextMenuTrigger };
export default ContextMenu;

What you get

The component source, copied into your project by npx astrocraft-ui add overlays/context-menu — no package dependency, no CSS to fight. Whatever the paid blocks compose, this is it.