@jsenv/navi 0.29.73 → 0.29.75

package/dist/jsenv_navi.js

@@ -4,7 +4,7 @@
  */
 import { installImportMetaCssBuild, windowHeightSignal, windowWidthSignal, visualViewportHeightSignal, visualViewportWidthSignal, getAppHeight, getAppWidth, smallTouchScreenSignal } from "./jsenv_navi_side_effects.js";
 export { coarsePointerSignal, disableVirtualKeyboardOverlay } from "./jsenv_navi_side_effects.js";
-import { elementIsFocusable, createPubSub, dispatchInternalCustomEvent, dispatchCustomEvent, getVisuallyVisibleInfo, getFirstVisuallyVisibleAncestor, getElementSignature, findEvent, createValueEffect, findFocusDelegateTarget, findFocusable, allowWheelThrough, dispatchPublicCustomEvent, resolveCSSColor, ELEMENT_SIZE_CHANGE, findSelfOrAncestorFixedPosition, visibleRectEffect, pickPositionRelativeTo, getBorderSizes, getPaddingSizes, applyNewPosition, measureLongestVisualLineWidth, chainEvent, waitForPressHeld, suppressClickAfterGesture, startDragToTravel, markDragSource, startDragTo, createIterableWeakSet, createEventGroupLogger, getKeyboardEventDefaultAction, activeElementSignal, normalizeStyle, mergeOneStyle, getPositionedParent, mergeTwoStyles, normalizeStyles, resolveCSSSize, hasCSSSizeUnit, resolveOklchLightness, contrastColor, closestOpenableAncestor, isAncestorOpen, observeAncestorOpenState, getAncestorOpenType, clickIsSuppressed, scrollRoomTowards, parsePositionArea, snapToPixel, trapFocusInside, trapScrollInside, onAncestorReopen, createGroupTransitionController, getBorderRadius, preventIntermediateScrollbar, createOpacityTransition, watchWheelTravel, findBefore, findAfter, initFocusGroup, scrollIntoViewScoped, getScrollContainer, canScroll, measureWidestChildRow, performTabNavigation, wheelGestureIsTakenFrom, releaseWheelGesture, claimWheelGesture, dragAfterIntent, stickyAsRelativeCoords, createDragToMoveGestureController, getDropTargetInfo, setStyles, useActiveElement, stringifyStyle as stringifyStyle$1 } from "@jsenv/dom";
+import { elementIsFocusable, createPubSub, dispatchInternalCustomEvent, dispatchCustomEvent, getVisuallyVisibleInfo, getFirstVisuallyVisibleAncestor, getElementSignature, findEvent, createValueEffect, findFocusDelegateTarget, findFocusable, allowWheelThrough, dispatchPublicCustomEvent, resolveCSSColor, ELEMENT_SIZE_CHANGE, findSelfOrAncestorFixedPosition, visibleRectEffect, pickPositionRelativeTo, getBorderSizes, getPaddingSizes, applyNewPosition, measureLongestVisualLineWidth, chainEvent, waitForPressHeld, suppressClickAfterGesture, startDragToTravel, markDragSource, startDragTo, createIterableWeakSet, createEventGroupLogger, getKeyboardEventDefaultAction, activeElementSignal, normalizeStyle, mergeOneStyle, getPositionedParent, mergeTwoStyles, normalizeStyles, resolveCSSSize, hasCSSSizeUnit, resolveOklchLightness, contrastColor, closestOpenableAncestor, isAncestorOpen, observeAncestorOpenState, getAncestorOpenType, clickIsSuppressed, isTouchDrivenEvent, scrollIntoViewScoped, scrollRoomTowards, parsePositionArea, snapToPixel, trapFocusInside, trapScrollInside, onAncestorReopen, createGroupTransitionController, getBorderRadius, preventIntermediateScrollbar, createOpacityTransition, watchWheelTravel, findBefore, findAfter, initFocusGroup, getScrollContainer, canScroll, measureWidestChildRow, performTabNavigation, wheelGestureIsTakenFrom, releaseWheelGesture, claimWheelGesture, dragAfterIntent, stickyAsRelativeCoords, createDragToMoveGestureController, getDropTargetInfo, setStyles, useActiveElement, stringifyStyle as stringifyStyle$1 } from "@jsenv/dom";
 export { clickIsSuppressed, contrastColor, findEvent, startDragTo } from "@jsenv/dom";
 import { signal, computed, effect, batch, untracked, useSignal } from "@preact/signals";
 import { createContext, isValidElement, h, Fragment, render, toChildArray, options, cloneElement } from "preact";
@@ -19345,10 +19345,48 @@ import.meta.css = [/* css */`
         outline-offset: calc(-1 * var(--navi-focus-outline-width));
         overflow: auto;
 
+        /* The same reading as the header's corners above, on all four: a body
+           follows the corners of the box it is drawn in — which is also what
+           it clips its content to, the overflow just above. */
+        border-top-left-radius: inherit;
+        border-top-right-radius: inherit;
+        border-bottom-right-radius: inherit;
+        border-bottom-left-radius: inherit;
+
         &:focus-visible {
           outline-style: solid;
         }
       }
+
+      /* A corner a header or a footer covers is not the body's to follow:
+         what the body meets there is their flat separator line, not a curve,
+         and a radius against it shows the box through the gap it opens. */
+      > [data-header] ~ [data-body] {
+        border-top-left-radius: 0;
+        border-top-right-radius: 0;
+      }
+      > [data-body]:has(~ [data-footer]) {
+        border-bottom-right-radius: 0;
+        border-bottom-left-radius: 0;
+      }
+
+      /* A body with no padding of its own holds content running edge to edge:
+         whatever sits at one of its ends is drawn ON the corner the body just
+         resolved, so a radius of its own there carves a notch out of it. The
+         body already clips to that corner, which makes "none" the right radius
+         for what lands on it — square, and the body draws the curve. The ask
+         travels down as a corner claim (see group.jsx) so a navi control
+         answers it wherever it sits inside. */
+      > [data-body][data-body-flush] {
+        > :first-child {
+          --x-corner-top-left-radius: 0;
+          --x-corner-top-right-radius: 0;
+        }
+        > :last-child {
+          --x-corner-bottom-right-radius: 0;
+          --x-corner-bottom-left-radius: 0;
+        }
+      }
     }
   }
 
@@ -19551,6 +19589,11 @@ const Box = props => {
   }
   if (body) {
     rest["data-body"] = "";
+    // Padding is what decides whether the content reaches the body's own
+    // corners — see the corner claims in this file's CSS.
+    if (!PADDING_PROP_NAMES.some(name => isNonZeroSpacing(rest[name]))) {
+      rest["data-body-flush"] = "";
+    }
   }
   const defaultDisplay = getDefaultDisplay(TagName);
   // Read the parent flow early so we can use it when display="inherit" is requested.
@@ -20015,6 +20058,16 @@ const shouldInjectSeparatorBetween = (left, right) => {
   }
   return true;
 };
+const PADDING_PROP_NAMES = ["padding", "paddingX", "paddingY", "paddingTop", "paddingRight", "paddingBottom", "paddingLeft"];
+const isNonZeroSpacing = value => {
+  if (value === undefined || value === null || value === false) {
+    return false;
+  }
+  if (value === 0 || value === "0" || value === "none") {
+    return false;
+  }
+  return true;
+};
 
 const useDebounceTrue = (value, delay = 300) => {
   const [debouncedTrue, setDebouncedTrue] = useState(false);
@@ -28546,7 +28599,21 @@ const prepareFocusTransfer = (prepareEvent, debugFocus) => {
     focusedElement,
     focusVisible,
 
-    transferFocus: (transferEvent, containerEl) => {
+    /**
+     * Moves the focus into `containerEl`, on the element the ladder above
+     * picks.
+     *
+     * `getDelay(target)` — asked once the target is known, answers how many
+     * milliseconds to wait before actually focusing it. The ladder is what
+     * decides WHO gets the focus and it may only run once (it consumes the
+     * autofocus-restore mark), so a caller with a policy about WHEN cannot
+     * resolve the target itself to make up its mind: it is handed the answer
+     * instead. Returns a cancel function when it did delay, so a container
+     * closing before the delay is up takes back a focus it never gave;
+     * undefined when it focused straight away and there is nothing to take
+     * back.
+     */
+    transferFocus: (transferEvent, containerEl, { getDelay } = {}) => {
       let target;
       let reason;
       const lastFocused = clearAutofocusRestore(containerEl);
@@ -28574,24 +28641,39 @@ const prepareFocusTransfer = (prepareEvent, debugFocus) => {
         }
       }
       if (!target) {
-        return;
+        return undefined;
       }
       // The modality speaks for the transfer, but an editable target outranks
       // it: it draws its ring on any focus (see isMatchingFocusVisible), so
       // the native :focus-visible is told the same.
       const targetFocusVisible = focusVisible || isEditableTarget(target);
+      const giveFocus = () => {
+        debugFocus(
+          transferEvent,
+          `Moving focus to ${getElementSignature(target)}.focus({ preventScroll: true, focusVisible: ${targetFocusVisible} }) (reason: ${reason})`,
+        );
+        target.focus({
+          preventScroll: true,
+          focusVisible: targetFocusVisible,
+        });
+        if (target.hasAttribute("navi-autofocus-select")) {
+          target.select();
+          target.scrollLeft = 0;
+        }
+      };
+      const delay = getDelay?.(target) || 0;
+      if (!delay) {
+        giveFocus();
+        return undefined;
+      }
       debugFocus(
         transferEvent,
-        `Moving focus to ${getElementSignature(target)}.focus({ preventScroll: true, focusVisible: ${targetFocusVisible} }) (reason: ${reason})`,
+        `Delaying focus to ${getElementSignature(target)} by ${delay}ms`,
       );
-      target.focus({
-        preventScroll: true,
-        focusVisible: targetFocusVisible,
-      });
-      if (target.hasAttribute("navi-autofocus-select")) {
-        target.select();
-        target.scrollLeft = 0;
-      }
+      const timeout = setTimeout(giveFocus, delay);
+      return () => {
+        clearTimeout(timeout);
+      };
     },
 
     restoreFocus: (restoreEvent) => {
@@ -28633,6 +28715,21 @@ const getFocusedBeforeTransfer = (e) => {
   return document.activeElement;
 };
 
+// How long a popup waits before handing the focus to a field, when giving it
+// is what raises the on-screen keyboard.
+//
+// The focus is normally given as early as possible. But a popup places itself
+// against the viewport, and on a phone the keyboard takes a third of that
+// viewport away the moment a field receives focus — so the two landing in the
+// same tick means the popup is still arriving when the room under it changes,
+// and it re-places itself mid-entrance. Waiting lets it settle first, and the
+// keyboard then shrinks a box that has stopped moving.
+//
+// Long enough to outlast an entrance transition rather than merely reaching
+// the next frame: what has to be over is the popup MOVING, not one paint of
+// it.
+const FOCUS_DELAY_ON_KEYBOARD_MS = 250;
+
 /**
  * Owns open/close decision-making for a popup (Dialog or Popover): guards
  * against duplicate requests and notifies the popup owner's own reactions.
@@ -28871,8 +28968,32 @@ const createOpenController = (
         // once mousedown.preventDefault() has kept focus from landing
         // anywhere yet.
 
-        focusTransfer.transferFocus(e, el);
+        // Two conditions, and both are about THIS opening rather than about
+        // the device:
+        // - the interaction: only a finger raises a virtual keyboard, and a
+        //   hybrid tablet answers "coarse" to every device-level signal
+        //   whichever of its two inputs was just used — the open event still
+        //   remembers which one it was. An opening with no pointer in it at
+        //   all (a keyboard shortcut, defaultOpen, an app calling open()) is
+        //   not one either.
+        // - the target: focusing a button raises nothing, so there is nothing
+        //   to wait for and the focus stays immediate. Only a field the
+        //   keyboard comes up for is worth delaying — which is why the
+        //   decision is taken on the resolved target, inside transferFocus.
+        const openedByTouch = Boolean(
+          findEvent(requestOpenEvent, isTouchDrivenEvent),
+        );
+        const cancelPendingFocus = focusTransfer.transferFocus(e, el, {
+          getDelay: (target) =>
+            openedByTouch && isEditableTarget(target)
+              ? FOCUS_DELAY_ON_KEYBOARD_MS
+              : 0,
+        });
         return (closeEvent) => {
+          // Closed before the delay was up: the focus was never given, so it
+          // must not be given now — to a field inside a popup on its way out,
+          // raising the keyboard as it goes.
+          cancelPendingFocus?.();
           markAutofocusRestoreOnClose(el, closeEvent, focusedAtClose);
           const focusoutEvent = findEvent(closeEvent, "focusout");
           if (focusoutEvent) {
@@ -29141,6 +29262,60 @@ const flushSyncRendering = (fn) => {
  */
 
 
+/**
+ * Whether a visibleRectEffect delivery is one that can have taken height away
+ * from a popup, and so pushed whatever holds focus out of sight:
+ * - "resize": the window/visual viewport settled — which is also how the
+ *   on-screen keyboard arrives, overlay or not (window_size.js);
+ * - ELEMENT_SIZE_CHANGE: the popup's own box measured different;
+ * - "focusin": the focus-settled re-measure, for the room that changes with
+ *   nothing announcing it (subscribeFocusSettled in window_size.js).
+ *
+ * Everything else is a scroll of one kind or another, where nothing got
+ * smaller and scrolling the focused element back would fight the very gesture
+ * that fired it.
+ */
+const mayHaveHiddenFocus = (event) => {
+  const type = event?.type;
+  return (
+    type === "resize" || type === ELEMENT_SIZE_CHANGE || type === "focusin"
+  );
+};
+
+/**
+ * Scrolls whatever holds focus inside `popupEl` back into view, if the popup
+ * getting shorter has pushed it out.
+ *
+ * The case this exists for: a field low in the scrolling body of a popup that
+ * also has a footer (box.jsx — with a body, the body is the only thing that
+ * scrolls and the footer is a sibling sitting right under it). Focusing the
+ * field makes the browser scroll it into view, which it does against the
+ * popup's height AT THAT MOMENT; the on-screen keyboard then opens and takes
+ * that height away. The body shrinks, its scrollTop does not move, so the
+ * content slides down relative to the shorter scrollport and the field ends up
+ * past its bottom edge — visually, swallowed by the footer. The browser does
+ * not redo a scroll-into-view it already answered, so this does.
+ *
+ * Scoped to the field's own scroll container (never the page): a popup traps
+ * scrolling precisely so the document underneath cannot move, and a plain
+ * scrollIntoView walks past a container whose scrollbar isn't visible — see
+ * scrollIntoViewScoped's own doc.
+ *
+ * "nearest": the smallest scroll that makes it visible, and none at all when
+ * it already is — so this is free to call on every resize, and never fights
+ * where the user had scrolled to.
+ */
+const keepFocusedElementVisible = (popupEl) => {
+  const { activeElement } = document;
+  if (!activeElement || activeElement === popupEl) {
+    return;
+  }
+  if (!popupEl.contains(activeElement)) {
+    return;
+  }
+  scrollIntoViewScoped(activeElement, { block: "nearest" });
+};
+
 /**
  * Calls `onSettled` once `el`'s current CSS transition is over — via
  * `transitionend`, with a safety `setTimeout` fallback matching the longest
@@ -29852,10 +30027,13 @@ installImportMetaCssBuild(import.meta);/**
  * `positionArea` accepts the same grammar Popover does (see
  * popup_shared.js), even though several combinations land identically here
  * since Dialog is never really anchored — kept distinct anyway because
- * `positionArea` still picks which animation direction plays. `anchor` only
- * ever affects the `--anchor-width`/`--anchor-height` CSS vars (sizing the
- * dialog relative to whatever opened it) — Dialog's own positioning is never
- * relative to it, unlike Popover.
+ * `positionArea` still picks which animation direction plays. `anchor` is
+ * inert here unless `sizeFromAnchor` asks for it: a dialog is a surface of
+ * its own, sized by its content, not a panel grown out of the control that
+ * opened it — that is Popover's job. With `sizeFromAnchor`, the anchor's box
+ * reaches the `--anchor-width`/`--anchor-height` CSS vars and becomes a
+ * min-width/min-height floor. Either way Dialog's own positioning is never
+ * relative to the anchor, unlike Popover.
  *
  * Two rendering strategies, picked via `layer`: `DialogAsModal` (a real
  * `<dialog>`, `showModal()`, top layer — native focus trap,
@@ -30340,17 +30518,24 @@ const css$X = /* css */`
  *   value is used as-is.
  * @param {string} [props.animationDuration] - Maps to
  *   `--popup-animation-duration`.
- * @param {Element|{current: Element}|string} [props.anchor] - Only ever sizes
- *   the dialog via the `--anchor-width`/`--anchor-height` CSS vars — never
- *   used for positioning (see this file's top comment). Defaults to whatever
+ * @param {Element|{current: Element}|string} [props.anchor] - Never used for
+ *   positioning (see this file's top comment), and ignored entirely unless
+ *   `sizeFromAnchor` is set — then it sizes the dialog via the
+ *   `--anchor-width`/`--anchor-height` CSS vars. Defaults to whatever
  *   triggered the open (`e.detail.anchor`), if any. A string is resolved via
  *   `document.getElementById` when the dialog opens — see popover.jsx's own
  *   `anchor` doc for why (mainly `defaultOpen`).
+ * @param {boolean} [props.sizeFromAnchor=false] - Whether the dialog takes the
+ *   anchor's width/height as a min-width/min-height floor
+ *   (`--anchor-width`/`--anchor-height`). Off by default: unlike a popover,
+ *   a dialog is not attached to what opened it, so following that element's
+ *   box is a deliberate choice (a picker-style surface meant to read as the
+ *   trigger's own continuation), not the norm.
  * @param {"override"|"ignore"} [props.anchorCustomEventDetail="override"] -
  *   Whether an explicit `anchor` prop takes precedence over (`"override"`,
  *   default) or is ignored in favor of (`"ignore"`) whatever anchor the
  *   triggering event carried. Same prop as Popover's, applied to the only
- *   thing an anchor does here: sizing (`--anchor-width`/`--anchor-height`).
+ *   thing an anchor can do here: sizing, and only under `sizeFromAnchor`.
  * @param {string} [props.minWidth] - Maps to `--dialog-min-width`; clamped
  *   so it can never push the dialog past `--dialog-maxmax-width` (the
  *   viewport/container-spacing ceiling) regardless of how large a value is
@@ -30609,12 +30794,15 @@ const useDialogProps = props => {
     // once, held at that size while open. See this prop's own JSDoc above.
     sizing = "auto",
     animation,
-    // Only ever affects --anchor-width/--anchor-height (see this file's top
-    // comment) — Dialog's own positioning is never relative to it.
+    // Inert unless sizeFromAnchor below (see this file's top comment) —
+    // Dialog's own positioning is never relative to it.
     anchor,
+    // Opt-in: --anchor-width/--anchor-height are only set when this is true.
+    // See this prop's own JSDoc above for why a dialog does not follow its
+    // trigger's box by default.
+    sizeFromAnchor = false,
     // Same meaning as Popover's own prop, applied to the only thing an anchor
-    // does here: sizing. "ignore" is how a dialog that must not inherit its
-    // trigger's width says so (SidePanel does exactly that).
+    // can do here: sizing under sizeFromAnchor.
     anchorCustomEventDetail = "override",
     // Makes the dialog itself a valid focus target so
     // autoFocus="last-resort" below has somewhere to land when it contains
@@ -30809,7 +30997,7 @@ const useDialogProps = props => {
       // see openLocalDialogCount's own comment
       dialogEl.style.setProperty("--dialog-stack-order", openLocalDialogCount++);
     }
-    if (anchorElement) {
+    if (sizeFromAnchor && anchorElement) {
       const {
         width,
         height
@@ -30977,6 +31165,11 @@ const useDialogProps = props => {
       // handled generically by applyNewPosition itself (dispatches
       // navi_position_change on every call) — nothing to do here.
     };
+    // Cleared here rather than on close, where the box is deliberately left
+    // frozen at the size it was closing at (see the closing function's own
+    // comment): this opening has its own content to be measured against, and
+    // measuring it inside last time's box would answer with last time's size.
+    unfreezeSize(dialogEl);
     positionDialog();
     if (sizing === "frozen") {
       // After positionDialog: the caps it writes
@@ -30999,6 +31192,12 @@ const useDialogProps = props => {
       event
     }) => {
       positionDialog(event);
+      // Only for what can have taken height away from the dialog — a
+      // scroll never does, and re-scrolling on one would fight the finger
+      // that caused it. See keepFocusedElementVisible's own doc.
+      if (mayHaveHiddenFocus(event)) {
+        keepFocusedElementVisible(dialogEl);
+      }
     }, {
       event: e,
       skipElementResize: true
@@ -31051,6 +31250,12 @@ const useDialogProps = props => {
     }
     const hasCssTransitionAnimation = Boolean(resolvedAnimation);
     const cancelOpenInteractionSuppression = !silent && hasCssTransitionAnimation ? suppressPointerEventsDuringTransition(dialogEl) : null;
+    // Handing the focus to a field is what raises the on-screen keyboard, and
+    // the keyboard takes away the very room this dialog was just placed
+    // against — so on a touch-driven opening the transfer waits for the
+    // entrance to be over. Decided by transferFocusOnOpen, the only place that
+    // knows WHICH element is about to be focused (open_controller.js and its
+    // FOCUS_DELAY_ON_KEYBOARD_MS).
     const restoreFocus = openController.transferFocusOnOpen(dialogEl);
 
     // isModal outside-click detection (see this file's top comment for why
@@ -31116,9 +31321,16 @@ const useDialogProps = props => {
       // property is actually present — harmless the rest of the time.
       dialogEl.setAttribute("navi-hidden", "");
       dialogEl.close();
-      // The freeze only ever holds for one opening: the next one has its own
-      // content to be measured against.
-      unfreezeSize(dialogEl);
+      // Held at the size it has right now, for the whole way out. cleanup()
+      // below already stops the JS repositioning, but the size is CSS-driven
+      // (--x-dialog-max-height, and `height` outright under expandY) and
+      // keeps following the visual viewport on its own — so a dialog closed
+      // while the keyboard is up grows back to fill the room the keyboard is
+      // giving back, WHILE fading out. Coherent, and still wrong to watch: a
+      // box being dismissed has nothing left to adapt to, and the growth
+      // reads as something happening at the exact moment nothing should. The
+      // next opening clears it (see openEffect's own unfreezeSize).
+      freezeSize(dialogEl);
       cancelOpenInteractionSuppression?.();
       if (hasCssTransitionAnimation) {
         suppressPointerEventsDuringTransition(dialogEl);
@@ -32430,6 +32642,12 @@ const usePopoverProps = props => {
       }
       popoverEl.removeAttribute("data-anchor-out-of-view");
       positionPopover(event);
+      // Same as Dialog's own — a popup with a scrolling body and a footer
+      // swallows the field it just got shorter around. See
+      // keepFocusedElementVisible's own doc in popup_shared.js.
+      if (mayHaveHiddenFocus(event)) {
+        keepFocusedElementVisible(popoverEl);
+      }
     }, {
       event: e,
       // it's ok for the popover to become unsync with the anchor size
@@ -38817,24 +39035,34 @@ const ROUTE_TRAVEL_ATTRIBUTE = "data-navi-route-travel";
 // included).
 
 const css$T = /* css */`
-  /* The marked region is a picture of its own during every view transition of
-     the document — which is what keeps it out of the root snapshot, where its
-     place would otherwise be blank. */
-  [data-navi-route-transition-area] {
+  /* The marked region is a picture of its own for the length of a transition of
+     OURS, and only then — the name is what makes the pages a picture the
+     movement below can carry.
+
+     Named outside that, it would be a picture during every view transition the
+     APPLICATION starts — two rows swapping, a list changing — and a page is
+     several screens tall: its picture is the whole element, drawn in the top
+     layer from wherever the element starts, so it paints over the fixed bars
+     and past the bottom of the screen for the length of a movement that has
+     nothing to do with the pages. Unnamed, it stays part of the document's own
+     picture, where the browser cuts it at the viewport like everything else. */
+  :root[data-navi-route-transition] [data-navi-route-transition-area] {
     view-transition-name: navi-route-transition;
   }
 
-  /* A named descendant — a row named for a reorder gesture, a thumbnail named
-     for a morph — is a hole in the area's picture and a group of its own at the
-     top of the tree: it stands still and cross-fades on its own clock while the
-     pages move. Nested groups put it back INSIDE the area's picture, so it
-     travels with the pages and is cut at their edge. Said here rather than
-     erasing the name: a name inside the area is legitimate, and "contain" says
-     "these move with the page" where "none" would say "these do not exist". A
-     browser without nested groups is warned instead (see
+  /* A named descendant — a thumbnail named for a morph, a row named for a
+     reorder gesture — is a hole in the area's picture and a group of its own.
+     Nested groups keep that group inside the area's, which is what cuts it at
+     the pages' edge instead of letting it paint across the screen. What it does
+     NOT do is make it travel: the movement is carried by the area's two
+     pictures, and a group is not one of them, so a named descendant stands
+     where it was captured while the pages slide under it. A morph wants exactly
+     that; a component that names its parts for changes of its own does not, and
+     drops its names for the length of the movement (see list.jsx). A browser
+     without nested groups is warned instead (see
      warnAboutNamesEscapingArea). */
   @supports (view-transition-group: contain) {
-    [data-navi-route-transition-area] {
+    :root[data-navi-route-transition] [data-navi-route-transition-area] {
       view-transition-group: contain;
     }
   }
@@ -45723,9 +45951,12 @@ installImportMetaCssBuild(import.meta);/**
  *    along the bar it adds to the padding asked for. Note that every
  *    `env(safe-area-inset-*)` is 0 unless the page asks for it:
  *    `<meta name="viewport" content="…, viewport-fit=cover">`.
- * 4. **Its hairline is a box-shadow, not a border.** A real border would eat
- *    into the size; a box-shadow draws the identical line and stays out of
- *    layout.
+ * 4. **Its hairline is part of its box.** The line covers the content just as
+ *    the bar does, so the room given back has to include it — a line drawn
+ *    outside the box (a box-shadow, an outline) is a line the content scrolls
+ *    under, and a line a page transition paints over. It is a real border,
+ *    added to the size asked for exactly like the notch inset is, so the
+ *    content still gets the size the prop names.
  */
 const css$M = /* css */`
   @layer navi {
@@ -45785,39 +46016,50 @@ const css$M = /* css */`
     }
 
     /* Across the bar, the inset of the edge it is pinned to is padding AND is
-       added to the size: the background then runs under the notch while the
-       content keeps the whole width/height asked for. */
+       added to the size, and the hairline on the content side is added the
+       same way: the background then runs under the notch, the line stands
+       clear of the content, and the content keeps the whole width/height asked
+       for. */
     &[data-area="top"] {
       top: var(--navi-app-inset-top);
-      height: calc(var(--navi-fixed-bar-height) + env(safe-area-inset-top));
+      height: calc(
+        var(--navi-fixed-bar-height) + env(safe-area-inset-top) +
+          var(--navi-fixed-bar-border-width)
+      );
       padding-top: env(safe-area-inset-top);
-      box-shadow: 0 var(--navi-fixed-bar-border-width) 0
+      border-bottom: var(--navi-fixed-bar-border-width) solid
         var(--navi-fixed-bar-border-color);
     }
     &[data-area="bottom"] {
       bottom: var(--navi-app-inset-bottom);
-      height: calc(var(--navi-fixed-bar-height) + env(safe-area-inset-bottom));
+      height: calc(
+        var(--navi-fixed-bar-height) + env(safe-area-inset-bottom) +
+          var(--navi-fixed-bar-border-width)
+      );
       padding-bottom: env(safe-area-inset-bottom);
-      box-shadow: 0 calc(-1 * var(--navi-fixed-bar-border-width)) 0
+      border-top: var(--navi-fixed-bar-border-width) solid
         var(--navi-fixed-bar-border-color);
     }
     &[data-area="left"] {
       left: var(--navi-app-inset-left);
-      width: calc(var(--navi-fixed-bar-width) + env(safe-area-inset-left));
+      width: calc(
+        var(--navi-fixed-bar-width) + env(safe-area-inset-left) +
+          var(--navi-fixed-bar-border-width)
+      );
       padding-left: env(safe-area-inset-left);
-      box-shadow: var(--navi-fixed-bar-border-width) 0 0
+      border-right: var(--navi-fixed-bar-border-width) solid
         var(--navi-fixed-bar-border-color);
     }
     &[data-area="right"] {
       right: var(--navi-app-inset-right);
-      width: calc(var(--navi-fixed-bar-width) + env(safe-area-inset-right));
+      width: calc(
+        var(--navi-fixed-bar-width) + env(safe-area-inset-right) +
+          var(--navi-fixed-bar-border-width)
+      );
       padding-right: env(safe-area-inset-right);
-      box-shadow: calc(-1 * var(--navi-fixed-bar-border-width)) 0 0
+      border-left: var(--navi-fixed-bar-border-width) solid
         var(--navi-fixed-bar-border-color);
     }
-    &[data-border="none"] {
-      box-shadow: none;
-    }
   }
 `;
 const FixedBarStyleCSSVars = {
@@ -45851,9 +46093,10 @@ const FixedBarStyleCSSVars = {
  * @param {string|number} [props.width] - …and for one on a side. The safe-area
  *   inset is NOT part of it: it is added on top, so the content keeps the size
  *   asked for.
- * @param {boolean} [props.border=true] - The hairline on the content side.
- *   Drawn with a box-shadow so it never eats into the size; give it a
- *   `borderWidth`/`borderColor`, or `border={false}` for none.
+ * @param {boolean} [props.border=true] - The hairline on the content side. It
+ *   is added to the size rather than taken out of it, and counts in the room
+ *   the bar gives back; give it a `borderWidth`/`borderColor`, or
+ *   `border={false}` for none.
  * @param {string|number} [props.maxWidth] - Keeps the bar lined up with a
  *   content column narrower than the window (it stays centered).
  */
@@ -45866,9 +46109,16 @@ const FixedBar = ({
   import.meta.css = [css$M, "@jsenv/navi/src/layout/fixed_bar/fixed_bar.jsx"];
   const defaultRef = useRef();
   props.ref = props.ref || defaultRef;
+  // Said with the width the border rule reads rather than with an attribute of
+  // its own: the width is what the size calc adds, so a line asked away here
+  // is a line that takes no room either.
+  if (!border) {
+    props.borderWidth = "0px";
+  }
   // Whichever of width/height crosses the edge the bar sits on is what the
   // content has to be given back — and the bar's border box already IS that:
-  // the size it was given plus the inset of that edge. Measured rather than
+  // the size it was given, the inset of that edge, and the hairline standing
+  // between it and the content. Measured rather than
   // rebuilt as a calc() expression, so a size coming from anywhere — a prop, a
   // theme variable, the content itself — is reserved just the same, and each
   // `env()` inset stays the browser's business alone.
@@ -45915,7 +46165,6 @@ const FixedBar = ({
   return jsx(Box, {
     baseClassName: "navi_fixed_bar",
     "data-area": area,
-    "data-border": border ? undefined : "none",
     ...props,
     styleCSSVars: FixedBarStyleCSSVars,
     children: children
@@ -54442,9 +54691,9 @@ installImportMetaCssBuild(import.meta);/**
  *
  * `layer` (shared by both — picks the top-layer vs. local-container rendering
  * strategy either way) and `anchorCustomEventDetail` (shared too: Popover
- * resolves an anchor to position against, Dialog to size itself from) pass
- * through untouched via `...rest` to whichever of Popover/Dialog actually
- * renders.
+ * resolves an anchor to position against, Dialog only to size itself from,
+ * and only under its own `sizeFromAnchor`) pass through untouched via
+ * `...rest` to whichever of Popover/Dialog actually renders.
  */
 const css$A = /* css */`
   @layer navi {
@@ -54482,13 +54731,12 @@ const css$A = /* css */`
  * @param {"top"|"local"} [props.layer] - Forwarded as-is to whichever of
  *   `Dialog`/`Popover` renders — see either component's own doc.
  * @param {Element|{current: Element}} [props.anchor] - Forwarded as-is —
- *   sizing-only for `Dialog`, positioning for `Popover` (see each
- *   component's own doc for what it actually does there).
+ *   positioning for `Popover`, and for `Dialog` sizing only, and only when
+ *   `sizeFromAnchor` is also passed (see each component's own doc).
  * @param {"override"|"ignore"} [props.anchorCustomEventDetail] - Forwarded
  *   as-is to both — what it governs differs (positioning for `Popover`,
- *   sizing for `Dialog`), but "ignore whatever anchor the triggering event
- *   carried" has to mean the same thing in either mode, or the same
- *   `<Popup>` usage silently picks up its trigger's width on small screens.
+ *   `sizeFromAnchor` sizing for `Dialog`), but "ignore whatever anchor the
+ *   triggering event carried" has to mean the same thing in either mode.
  * @param {string} [props.marginWithAnchor] - **Popover-only**, destructured
  *   out so it can't leak onto the real `<dialog>` element as a stray DOM
  *   attribute when `mode="dialog"` is picked.
@@ -54691,12 +54939,17 @@ installImportMetaCssBuild(import.meta);const css$z = /* css */`
 
         /* No fallback on purpose (same as --popover-max-height above): unset
            picker props leave these declarations invalid at computed-value
-           time, so the dialog keeps its own ceilings. */
+           time, so the dialog keeps its own floors/ceilings. */
+        --dialog-min-width: var(--picker-dialog-min-width);
+        --dialog-min-height: var(--picker-dialog-min-height);
         --dialog-max-width: var(--picker-dialog-max-width);
         --dialog-max-height: var(--picker-dialog-max-height);
 
-        /* Dialog itself already sizes min-width off --anchor-width — only
-           the cursor reset below is picker-specific here. */
+        /* Nothing bridges the trigger's width in here: a dialog does not
+           follow its anchor's box (dialog.jsx, sizeFromAnchor) — it is not
+           visually attached to the trigger, so it is sized by its content,
+           and dialogMinWidth/dialogMinHeight are how a caller says otherwise.
+           Only the cursor reset below is picker-specific here. */
         cursor: default; /* Reset pointer cursor within the select */
 
         /* Dialog already applies display: flex to [open] itself, but
@@ -54718,24 +54971,10 @@ installImportMetaCssBuild(import.meta);const css$z = /* css */`
     }
 
     /* popupWidthFitContent (picker.jsx): drop the trigger-width floor so the
-       popup shrinks to its content. Inherits down to the popover. */
+       popup shrinks to its content. Popover-only — the dialog has no such
+       floor to drop (see the dialog block above). */
     &[data-popup-width-fit-content] {
       --picker-popover-min-width: 0px;
-
-      /* The popover var above only reaches the popover — the dialog reads
-         --anchor-width directly for its own min-width floor (dialog.jsx). A
-         modal dialog isn't visually attached to the trigger, so with
-         fit-content we drop that floor here too, letting the content size the
-         dialog like the popover. (More specific than dialog.jsx's own
-         .navi_dialog rule; both are unlayered, so this wins.) */
-      &[aria-haspopup="dialog"] {
-        .navi_dialog {
-          min-width: min(
-            var(--dialog-min-width, 0px),
-            var(--x-dialog-max-width)
-          );
-        }
-      }
     }
   }
 `;
@@ -57048,7 +57287,26 @@ const css$w = /* css */`
     flex-direction: column;
     background-color: var(--x-list-background-color);
     border: var(--x-list-border-width) solid var(--x-list-border-color);
-    border-radius: var(--x-list-border-radius);
+    /* Squared from the outside, corner by corner: whoever draws the surface
+       the list is laid on says which corners are the list's to draw (a popup's
+       body does, see box.jsx), and each corner falls back to the list's own
+       radius when nothing asks for anything. */
+    border-top-left-radius: var(
+      --x-corner-top-left-radius,
+      var(--x-list-border-radius)
+    );
+    border-top-right-radius: var(
+      --x-corner-top-right-radius,
+      var(--x-list-border-radius)
+    );
+    border-bottom-right-radius: var(
+      --x-corner-bottom-right-radius,
+      var(--x-list-border-radius)
+    );
+    border-bottom-left-radius: var(
+      --x-corner-bottom-left-radius,
+      var(--x-list-border-radius)
+    );
 
     transition: opacity 0.2s ease;
     /* overflow:hidden is required on the container (not the inner scroll element)
@@ -57057,6 +57315,13 @@ const css$w = /* css */`
     overflow: hidden;
 
     .navi_list_scroll_container {
+      /* The ask stops here: this element is inside the list's frame, so a row
+         or a control it holds is not at the surface's corner. */
+      --x-corner-top-left-radius: initial;
+      --x-corner-top-right-radius: initial;
+      --x-corner-bottom-right-radius: initial;
+      --x-corner-bottom-left-radius: initial;
+
       width: inherit;
       min-width: inherit;
       max-width: var(--list-max-width, inherit);
@@ -57530,9 +57795,19 @@ const css$w = /* css */`
      without being contained animate across the page (the pictures live in the
      top layer, where no overflow of the document reaches them), which is worse
      than not animating at all. So a browser with no nested groups gets no name
-     either, and the change simply happens. */
+     either, and the change simply happens.
+
+     Named for a change of the list's own, and for that alone: while the PAGES
+     are the ones moving — a route transition, a route travel — the list is part
+     of what travels, and a picture of its own is precisely what does not
+     travel. A page is carried by its own picture; anything named inside it is
+     lifted out of that picture into a group of its own, which stays where it
+     was captured while the page slides away under it. So the names are dropped
+     for the length of such a movement and the list crosses the screen with the
+     page, as a block. */
   @supports (view-transition-group: contain) {
-    .navi_list_container[data-item-transition] {
+    :root:not([data-navi-route-transition], [data-navi-route-travel])
+      .navi_list_container[data-item-transition] {
       /* The list needs a name to be a group at all; which name does not matter,
          only that no other element in the document carries it. */
       view-transition-name: match-element;
@@ -62691,6 +62966,8 @@ const PickerStyleCSSVars = {
   "borderWidth": "--picker-border-width",
   "borderRadius": "--picker-border-radius",
   "popoverMaxHeight": "--picker-popover-max-height",
+  "dialogMinWidth": "--picker-dialog-min-width",
+  "dialogMinHeight": "--picker-dialog-min-height",
   "dialogMaxWidth": "--picker-dialog-max-width",
   "dialogMaxHeight": "--picker-dialog-max-height",
   "popupBackgroundColor": "--picker-popup-background-color",
@@ -74034,10 +74311,11 @@ installImportMetaCssBuild(import.meta);/**
  * `navi-side`/`data-layer` attributes) rather than computed in JS — read
  * the CSS block below instead of expecting a JS equivalent of it here.
  *
- * `anchorCustomEventDetail="ignore"` is required, not cosmetic, and in both
- * modes: without it Popover docks next to whatever triggered the open instead
- * of flush against the edge, and Dialog takes that trigger's width as its own
- * `min-width` floor (`--anchor-width`), overriding the `width` prop.
+ * `anchorCustomEventDetail="ignore"` is required, not cosmetic: without it
+ * Popover docks next to whatever triggered the open instead of flush against
+ * the edge. Dialog needs nothing here — it never sizes itself from an anchor
+ * unless asked to (`sizeFromAnchor`, see dialog.jsx), which a side panel
+ * never does: its `width`/`height` props are what size it.
  */
 const css = /* css */`
   .navi_side_panel {