/* Action menu. Sits inside `ui/popover`'s `.popover` shell, so this file owns
   the list and its rows and deliberately owns no surface, border, radius or
   shadow: those belong to the panel it is put in, and a second copy of them
   here would be a card inside a card.

   Read `ui/menu/CONTEXT.md` first. Selection and keyboard behaviour are
   `menu.js`'s, and none of it keys off a class. */

@layer components {
  .menu {
    display: grid;
    /* `role="menu"`, not `role="list"`, so the reset's
       `ol[role="list"], ul[role="list"] { list-style: none }` does not reach
       it and the rows would otherwise render with bullets. */
    list-style: none;
    padding: var(--space-2) var(--space-1);
    min-width: 12rem;
    max-height: min(60dvh, 24rem);
    overflow-y: auto;
    overscroll-behavior: contain;
  }

  .menu__item {
    display: flex;
    align-items: center;
    gap: var(--space-3);
    /* 44px on a touch pointer, per DESIGN.md section 4. A pointing device does
       not need the height and a menu with 44px rows on a desktop reads as a
       list of buttons rather than as a menu, so the floor moves with the
       input rather than being set once for the worst case. */
    min-height: calc(36px * var(--ui-scale));
    /* The floor went 32 -> 36 and the inline padding 12 -> 16: at 8px/12px the
       labels sat almost against the panel edge, which is the "cramped
       together" the owner called out on 2026-09-21. The RESPONSIVE floor
       above is untouched - a pointing device still does not get 44px rows,
       for the reason stated there. */
    padding: var(--space-2) var(--space-4);
    border-radius: 0;
    color: var(--text);
    font-size: var(--text-sm);
    line-height: var(--text-sm-lh);
    white-space: nowrap;
    cursor: pointer;
    transition: background-color var(--dur-2) var(--ease-out),
                color var(--dur-2) var(--ease-out);
  }

  @media (pointer: coarse) {
    .menu__item { min-height: calc(44px * var(--ui-scale)); }
  }

  /* Hover and keyboard focus land on the same treatment on purpose: this
     widget moves focus with the arrow keys, so the focused row IS the hovered
     row as far as the person using it is concerned, and two different
     highlights would read as two different selections. */
  .menu__item:hover,
  .menu__item:focus-visible {
    background: color-mix(in oklab, var(--text) 7%, transparent);
  }
  .menu__item:focus-visible {
    outline: 2px solid var(--focus-ring);
    outline-offset: -2px;
  }

  .menu__item[aria-disabled="true"] {
    color: var(--text-muted);
    cursor: not-allowed;
  }
  .menu__item[aria-disabled="true"]:hover { background: none; }

  /* A destructive action. The colour is the second signal, not the only one:
     the label is the first, and DESIGN.md section 7 requires a confirmation or
     an undo window behind the action itself, which is the caller's job and not
     something a stylesheet can supply. */
  .menu__item[data-danger] { color: var(--danger); }
  .menu__item[data-danger]:hover,
  .menu__item[data-danger]:focus-visible {
    background: color-mix(in oklab, var(--danger) 14%, transparent);
  }

  .menu__separator {
    height: 1px;
    margin: var(--space-1) var(--space-2);
    background: var(--border);
  }

  @media (prefers-reduced-motion: reduce) {
    .menu__item { transition: none; }
  }
}