@jsenv/navi 0.29.46 → 0.29.48

package/dist/jsenv_navi.js

@@ -16993,11 +16993,14 @@ const VISUAL_PROPS = {
 };
 const CONTENT_PROPS = {
   align: applyOnTwoProps("alignX", "alignY"),
+  /* The value the caller named is always written out, even when it matches
+     CSS's own initial value ("start" for justify-content, "stretch" for
+     align-items). Skipping it as a no-op only holds for a bare element: a
+     component whose stylesheet already centers its content (Picker in its icon
+     variant, for one) would keep centering, and alignX="start" would silently
+     do nothing — the one case where saying it explicitly matters most. */
   alignX: (value, { boxFlow }) => {
     if (boxFlow === "flex-y" || boxFlow === "inline-flex-y") {
-      if (value === "stretch") {
-        return undefined; // this is the default
-      }
       return { alignItems: value };
     }
     if (
@@ -17011,18 +17014,12 @@ const CONTENT_PROPS = {
       boxFlow === "grid" ||
       boxFlow === "inline-grid"
     ) {
-      if (value === "start") {
-        return undefined; // this is the default
-      }
       return { justifyContent: value };
     }
     return { textAlign: value };
   },
   alignY: (value, { boxFlow }) => {
     if (boxFlow === "flex-y" || boxFlow === "inline-flex-y") {
-      if (value === "start") {
-        return undefined;
-      }
       return { justifyContent: value };
     }
     if (
@@ -17035,9 +17032,6 @@ const CONTENT_PROPS = {
       boxFlow === "grid" ||
       boxFlow === "inline-grid"
     ) {
-      if (value === "stretch") {
-        return undefined;
-      }
       return { alignItems: value };
     }
     const verticalAlignMap = {
@@ -22147,7 +22141,10 @@ const useNavState = useNavStateBasic;
  * @param {Event} event What the user did.
  * @param {object} [options]
  * @param {boolean} [options.optional] No suitable target is not a warning.
- * @param {any} [options.value] Carried to whoever answers.
+ * @param {any} [options.value] What the command is about, carried to whoever
+ *   answers — and, for `--navi-open`/`--navi-toggle`, what the popup is opened
+ *   ON: it reaches its `onOpen` before the popup builds anything. Left out, a
+ *   source's own value (`<Button value={id}>`) is read instead.
  * @param {Element} [options.anchor] Where a popup this opens should be placed,
  *   when that is not the element asking: a menu opened by a press belongs at the
  *   point the press happened, and the row that was pressed is not that point.
@@ -22176,6 +22173,10 @@ const triggerNaviCommand = (
     // Whatever followed the colon: "--navi-go-to-slide:edit" → "edit".
     argument: command.includes(":") ? commandArgument(command) : undefined,
     anchor,
+    // What the command is about, said by the caller rather than read off the
+    // source: the attribute form has a `value` to read (`<Button value={id}>`),
+    // a JS decision has none, and both must be able to say the same thing.
+    value,
   });
   if (!execute) {
     if (optional) {
@@ -22812,28 +22813,42 @@ registerNaviCommand("--navi-nav-to", (source, event, { argument }) => {
   };
 });
 
-registerNaviCommand("--navi-toggle", (source, event, { anchor } = {}) => {
-  const target =
-    resolveExplicitTarget(source) || resolveClosestExpandable(source);
-  if (!target) {
-    return undefined;
-  }
-  return {
-    target,
-    implementation: () => {
-      const isExpanded = target.getAttribute("aria-expanded") === "true";
-      const customEventName = isExpanded
-        ? "navi_request_close"
-        : "navi_request_open";
-      return dispatchCustomEvent(target, customEventName, {
-        event,
-        source: resolveCommandProxySource(source),
-        anchor,
-      });
-    },
-  };
-});
-registerNaviCommand("--navi-open", (source, event, { anchor } = {}) => {
+registerNaviCommand(
+  "--navi-toggle",
+  (source, event, { anchor, value } = {}) => {
+    const target =
+      resolveExplicitTarget(source) || resolveClosestExpandable(source);
+    if (!target) {
+      return undefined;
+    }
+    return {
+      target,
+      implementation: () => {
+        const isExpanded = target.getAttribute("aria-expanded") === "true";
+        const customEventName = isExpanded
+          ? "navi_request_close"
+          : "navi_request_open";
+        return dispatchCustomEvent(target, customEventName, {
+          event,
+          source: resolveCommandProxySource(source),
+          anchor,
+          // Same as --navi-open below: the half of the toggle that opens says
+          // what it opens ON, and the half that closes carries it too so the
+          // popup never has to ask which half it just heard.
+          value:
+            value === undefined ? resolveCommandValue(source, event) : value,
+        });
+      },
+    };
+  },
+);
+// A popup that edits opens ON something, and the press is the only place that
+// knows which one. It says it with `value` — "what this is about", as
+// everywhere else — rather than with an argument, which says what the command
+// DOES: "open" is already a complete instruction, unlike --navi-go-to-slide.
+//   <Button value={radar.id} command="--navi-open" commandfor="radar-dialog">
+// The popup is told before it opens — see Dialog/Popover's `onOpen`.
+registerNaviCommand("--navi-open", (source, event, { anchor, value } = {}) => {
   const target =
     resolveExplicitTarget(source) || resolveClosestExpandable(source);
   if (!target) {
@@ -22849,6 +22864,7 @@ registerNaviCommand("--navi-open", (source, event, { anchor } = {}) => {
         event,
         source: resolveCommandProxySource(source),
         anchor,
+        value: value === undefined ? resolveCommandValue(source, event) : value,
       });
     },
   };
@@ -27021,37 +27037,45 @@ installImportMetaCssBuild(import.meta);const css$W = /* css */`
       --x-button-border-color: var(--callout-color);
     }
 
+    /* A variant states what the caller did NOT: the frameless ones below move
+       the DEFAULTS (--button-*) and never the resolved values (--x-button-*),
+       so a backgroundColor/background/borderColor prop — which lands inline on
+       this same element — still wins. Two things come with that: the
+       transparent default is written as a fallback of --button-background, so
+       the background prop feeds --button-background-color through it; and the
+       per-state defaults are re-pointed at the base one, otherwise the @layer
+       formulas (hover = 5% black over the background, readonly = the same)
+       would repaint a box the variant just took away. */
+
     /* discrete: background on hover, and nothing else — no box at rest, and no
        shrink when pressed. What is drawn IS the content (a chevron, a number,
        a word), and shrinking it under the finger reads as the content itself
        flinching rather than as a button being pressed. */
     &[data-variant="discrete"] {
       --button-border-width: 0;
-      --x-button-background-color: transparent;
-      --x-button-border-color: transparent;
+      --button-border-color: transparent;
+      --button-border-color-hover: var(--button-border-color);
+      --button-border-color-current: var(--button-border-color);
+      --button-border-color-readonly: var(--button-border-color);
+      --button-border-color-disabled: var(--button-border-color);
+      --button-background-color: var(--button-background, transparent);
+      /* The hover wash is mixed INTO the background instead of replacing it:
+         over the transparent default it is exactly the 8% of currentColor it
+         has always been, and over a backgroundColor the caller gave it darkens
+         that color rather than erasing it. */
+      --button-background-color-hover: color-mix(
+        in srgb,
+        currentColor 8%,
+        var(--button-background-color)
+      );
+      --button-background-color-readonly: var(--button-background-color);
+      --button-background-color-disabled: var(--button-background-color);
 
       &[data-pressed] {
         .navi_button_content {
           transform: none;
         }
       }
-
-      &[data-hover] {
-        --x-button-border-color: transparent;
-        --x-button-background-color: color-mix(
-          in srgb,
-          currentColor 8%,
-          transparent
-        );
-      }
-      &[data-readonly] {
-        --x-button-border-color: transparent;
-        --x-button-background-color: transparent;
-      }
-      &[data-disabled] {
-        --x-button-border-color: transparent;
-        --x-button-background-color: transparent;
-      }
     }
     /* bare: discrete, minus the background on hover. For a control whose own
        drawing IS the button (a carousel bullet, a swatch), where a box lighting
@@ -27060,13 +27084,16 @@ installImportMetaCssBuild(import.meta);const css$W = /* css */`
        on focus, commandable. */
     &[data-variant="bare"] {
       --button-border-width: 0;
-      --x-button-background-color: transparent;
-      --x-button-border-color: transparent;
+      --button-border-color: transparent;
+      --button-border-color-hover: var(--button-border-color);
+      --button-border-color-current: var(--button-border-color);
+      --button-border-color-readonly: var(--button-border-color);
+      --button-border-color-disabled: var(--button-border-color);
+      --button-background-color: var(--button-background, transparent);
+      --button-background-color-hover: var(--button-background-color);
+      --button-background-color-readonly: var(--button-background-color);
+      --button-background-color-disabled: var(--button-background-color);
 
-      &[data-hover] {
-        --x-button-background-color: transparent;
-        --x-button-border-color: transparent;
-      }
       &[data-pressed] {
         .navi_button_content {
           transform: none;
@@ -27075,36 +27102,34 @@ installImportMetaCssBuild(import.meta);const css$W = /* css */`
     }
     /* discrete-border: border on hover */
     &[data-variant="discrete-border"] {
-      --x-button-background-color: transparent;
+      --button-background-color: var(--button-background, transparent);
+      --button-background-color-hover: var(--button-background-color);
+      --button-background-color-readonly: var(--button-background-color);
+      --button-background-color-disabled: var(--button-background-color);
+      /* The border is the whole point of this variant: it is absent at rest
+         and drawn on hover, so only the resting color goes transparent — the
+         hover one keeps the @layer formula, now mixed from whatever
+         borderColor the caller gave. */
       --x-button-border-color: transparent;
 
       &[data-hover] {
         --x-button-border-color: var(--button-border-color-hover);
       }
-      &[data-readonly] {
-        --x-button-border-color: transparent;
-      }
+      &[data-readonly],
       &[data-disabled] {
         --x-button-border-color: transparent;
       }
     }
     /* border variant: no background, border only */
     &[data-variant="border"] {
-      --x-button-background-color: transparent;
-
-      &[data-hover] {
-        --x-button-background-color: color-mix(
-          in srgb,
-          currentColor 8%,
-          transparent
-        );
-      }
-      &[data-readonly] {
-        --x-button-background-color: transparent;
-      }
-      &[data-disabled] {
-        --x-button-background-color: transparent;
-      }
+      --button-background-color: var(--button-background, transparent);
+      --button-background-color-hover: color-mix(
+        in srgb,
+        currentColor 8%,
+        var(--button-background-color)
+      );
+      --button-background-color-readonly: var(--button-background-color);
+      --button-background-color-disabled: var(--button-background-color);
     }
     /* Last word on the shrink, over whatever the variant decided: the variant
        guesses from how the button is drawn, and that guess is wrong as soon as
@@ -27790,7 +27815,8 @@ const getFocusedBeforeTransfer = (e) => {
  * - `onClose(e)`: actually closing, not preventable — final reactions live here.
  *
  * The controller exposes matching action methods:
- * - `open()`: requests opening — runs `openEffect`, then `openHandler`.
+ * - `open()`: requests opening — calls the caller's `onOpen` (see below), then
+ *   `mountContent`/`openEffect`, then `openHandler`.
  * - `requestClose()`: requests closing — calls `onRequestClose` then `onClose`,
  *   stopping after the first if denied. The popup may choose to stay open.
  * - `close()`: closes for real — calls only `onClose`, skipping
@@ -27960,6 +27986,13 @@ const createOpenController = (
     // content is still waiting for a first open to be built. Called below,
     // before openEffect, so the popup measures and positions the real thing.
     mountContent: null,
+    // The caller's own `onOpen`, set by Dialog/Popover from their props on
+    // every render (like openEffect). Called BEFORE mountContent, so whatever
+    // it decides — which record this dialog is opening on — is already true by
+    // the time the content is built, positioned and shown. That order is the
+    // whole point: learning it afterwards means the content mounted on the
+    // previous subject first.
+    onOpen: null,
     // The counterpart, set only when the popup was told to throw its content
     // away on close (`unmountWhenClosed`). Called from performClose above.
     unmountContent: null,
@@ -28016,6 +28049,10 @@ const createOpenController = (
           }
         };
       };
+      // Before mountContent, which builds the content, and before openEffect,
+      // which shows it: what the popup opens ON has to be known before either
+      // (see `onOpen` above).
+      controller.onOpen?.(requestOpenEvent);
       // After prepareFocusTransfer, which has to record what held the focus
       // before anything inside the popup can claim it, and before openEffect,
       // which measures the popup to place it.
@@ -29026,16 +29063,16 @@ const css$V = /* css */`
       backdrop-filter: var(--navi-backdrop-capture-backdrop-filter);
     }
 
-    /* backdropAppearance, keyed off the originating element (a
+    /* backdropVariant, keyed off the originating element (a
        pseudo-element carries no attributes of its own — same reasoning as
        the capture rule just above). After the rules it overrides: same
        specificity, so order is what decides. showModal() still makes the
        page inert either way — only the paint goes away. */
-    &[data-backdrop-appearance="discrete"]::backdrop {
+    &[data-backdrop-variant="discrete"]::backdrop {
       background: var(--navi-backdrop-discrete-background);
       backdrop-filter: none;
     }
-    &[data-backdrop-appearance="none"]::backdrop {
+    &[data-backdrop-variant="invisible"]::backdrop {
       background: transparent;
       backdrop-filter: none;
     }
@@ -29162,11 +29199,11 @@ const css$V = /* css */`
     /* Same override as the via-attribute renderer's own ::backdrop rules
        above, on the real element this renderer uses instead — see them for
        the specificity/ordering reasoning. */
-    &[data-backdrop-appearance="discrete"] {
+    &[data-backdrop-variant="discrete"] {
       background: var(--navi-backdrop-discrete-background);
       backdrop-filter: none;
     }
-    &[data-backdrop-appearance="none"] {
+    &[data-backdrop-variant="invisible"] {
       background: transparent;
       backdrop-filter: none;
     }
@@ -29245,11 +29282,11 @@ const css$V = /* css */`
  *   both just absorb the click without closing (visually dimmed backdrop vs.
  *   not) — a dialog is always modal one way or another, so there's always
  *   at least a click-absorbing backdrop regardless of this prop.
- * @param {"auto"|"discrete"|"none"} [props.backdropAppearance="auto"] - How
+ * @param {"auto"|"discrete"|"invisible"} [props.backdropVariant="auto"] - How
  *   visible the backdrop is, independently of what it does. `"auto"`: the
  *   paint `pointerInteractionOutsideEffect` implies (dimmed for
  *   `"close"`/`"cancel"`, blurred glass for `"capture"`). `"discrete"`: a
- *   barely-there dim. `"none"`: fully transparent. The dialog stays modal
+ *   barely-there dim. `"invisible"`: fully transparent. The dialog stays modal
  *   either way — this only changes how much it insists visually, never what
  *   an outside click does or whether the page behind stays reachable.
  * @param {boolean} [props.scrollCapture] - Traps scroll gestures inside the
@@ -29305,6 +29342,13 @@ const css$V = /* css */`
  *   for the user to see it transition away from. `"interaction"` says the
  *   opposite — this dialog is mounted *because* the user just asked for it, so
  *   the mount is the opening and the entrance plays like any other.
+ * @param {(openEvent: CustomEvent) => void} [props.onOpen] - Called when it
+ *   opens, BEFORE its content is built, positioned or shown. What it opens ON
+ *   is in `openEvent.detail.value` — the value of whatever asked
+ *   (`<Button value={radar.id} command="--navi-open" commandfor="…">`), or the
+ *   `value` given to `triggerNaviCommand`. That order is the point: a dialog that
+ *   is "new" or "edit X" depending on the press must know which one it is
+ *   before what it holds is rendered.
  * @param {(event: Event) => void} [props.onClose] - Called when the dialog
  *   actually closes — not preventable (see `open_controller.js`'s own
  *   `onRequestClose`/`onClose` distinction; `onRequestClose` is where you'd
@@ -29379,7 +29423,11 @@ const UncontrolledDialog = props => {
     openController: openController,
     onnavi_request_open: e => {
       openController.open(e, {
-        anchor: e.detail?.anchor ?? e.detail?.source
+        anchor: e.detail?.anchor ?? e.detail?.source,
+        // What the command was about — a `<Button value={id}>` that opened
+        // this popup ON that id. Handed to `onOpen` before anything is
+        // built (see open_controller.js).
+        value: e.detail?.value
       });
     },
     onnavi_request_close: e => {
@@ -29503,7 +29551,7 @@ const useDialogProps = props => {
     // *does* (that's pointerInteractionOutsideEffect above). A dialog is
     // always modal, so "none" here never makes the page behind reachable:
     // it only stops the dim from being drawn.
-    backdropAppearance = "auto",
+    backdropVariant = "auto",
     scrollCapture: scrollCaptureProp,
     // "auto" (default) → the dialog follows its content. "frozen" → measured
     // once, held at that size while open. See this prop's own JSDoc above.
@@ -29522,11 +29570,20 @@ const useDialogProps = props => {
     // instead, so it's read here rather than left in `rest`.
     autoFocus = "last-resort",
     onKeyDown,
+    // Read here (rather than left in `rest`) for two reasons: it must never
+    // reach the DOM as an `onopen` attribute, and the controller — not this
+    // render — is what calls it, at the one moment that makes it useful (see
+    // openController.onOpen below).
+    onOpen,
     children: childrenProp,
     mountWhenClosed,
     unmountWhenClosed,
     ...rest
   } = props;
+  // Assigned on every render, like openEffect below, so it always closes over
+  // the latest prop. Called by openController.open() before the content is
+  // built: what this popup opens ON is known before anything reads it.
+  openController.onOpen = onOpen || null;
   const children = usePopupContentMount(openController, props.ref, {
     children: childrenProp,
     mountWhenClosed,
@@ -30025,7 +30082,7 @@ const useDialogProps = props => {
     "styleCSSVars": DIALOG_STYLE_CSS_VARS,
     "animationDuration": rest.animationDuration,
     "data-pointer-interaction-outside": pointerInteractionOutsideEffect,
-    "data-backdrop-appearance": backdropAppearance
+    "data-backdrop-variant": backdropVariant
   });
   Object.assign(contentProps, {
     tabIndex,
@@ -30058,7 +30115,7 @@ const useDialogProps = props => {
     // ::backdrop, same "a pseudo-element can't carry attributes" reasoning
     // as the prop just above (and harmless for the custom renderer, whose
     // real backdrop element gets it via backdropProps).
-    "data-backdrop-appearance": backdropAppearance,
+    "data-backdrop-variant": backdropVariant,
     "styleCSSVars": DIALOG_STYLE_CSS_VARS,
     ...rest,
     ...autoFocusProps,
@@ -30463,16 +30520,16 @@ const css$U = /* css */`
       backdrop-filter: var(--navi-backdrop-capture-backdrop-filter);
     }
 
-    /* backdropAppearance overrides whatever the effect above picked — same
+    /* backdropVariant overrides whatever the effect above picked — same
        specificity (class + one attribute), so these have to stay *after*
        them to win. Only the paint changes: the element is still rendered
        and still pointer-events: auto, so an outside click keeps doing
        exactly what pointerInteractionOutsideEffect says. */
-    &[data-backdrop-appearance="discrete"] {
+    &[data-backdrop-variant="discrete"] {
       background: var(--navi-backdrop-discrete-background);
       backdrop-filter: none;
     }
-    &[data-backdrop-appearance="none"] {
+    &[data-backdrop-variant="invisible"] {
       background: transparent;
       backdrop-filter: none;
     }
@@ -30540,11 +30597,11 @@ const css$U = /* css */`
  *   absorbs the click (dims the backdrop) without closing. Note this
  *   default differs from `Dialog`'s own (`"close"`) — a popover is
  *   typically a lightweight, non-modal affordance.
- * @param {"auto"|"discrete"|"none"} [props.backdropAppearance="auto"] - How
+ * @param {"auto"|"discrete"|"invisible"} [props.backdropVariant="auto"] - How
  *   visible the backdrop is, independently of what it does. `"auto"`: the
  *   paint `pointerInteractionOutsideEffect` implies (dimmed for
  *   `"close"`/`"cancel"`, blurred glass for `"capture"`). `"discrete"`: a
- *   barely-there dim. `"none"`: fully transparent. The backdrop is still
+ *   barely-there dim. `"invisible"`: fully transparent. The backdrop is still
  *   rendered and still catches outside clicks in every case — this only
  *   changes how much the popover insists on being the thing you deal with.
  *   Ignored when `pointerInteractionOutsideEffect="none"` (there is no
@@ -30607,6 +30664,13 @@ const css$U = /* css */`
  *   for the user to see it transition away from. `"interaction"` says the
  *   opposite — this popover is mounted *because* the user just asked for it, so
  *   the mount is the opening and the entrance plays like any other.
+ * @param {(openEvent: CustomEvent) => void} [props.onOpen] - Called when it
+ *   opens, BEFORE its content is built, positioned or shown. What it opens ON
+ *   is in `openEvent.detail.value` — the value of whatever asked
+ *   (`<Button value={radar.id} command="--navi-open" commandfor="…">`), or the
+ *   `value` given to `triggerNaviCommand`. That order is the point: a popover that
+ *   is "new" or "edit X" depending on the press must know which one it is
+ *   before what it holds is rendered.
  * @param {(event: Event) => void} [props.onClose] - Called when the popover
  *   actually closes — not preventable (see `open_controller.js`'s own
  *   `onRequestClose`/`onClose` distinction; `onRequestClose` is where you'd
@@ -30679,7 +30743,11 @@ const UncontrolledPopover = props => {
     openController: openController,
     onnavi_request_open: e => {
       openController.open(e, {
-        anchor: e.detail?.anchor ?? e.detail?.source
+        anchor: e.detail?.anchor ?? e.detail?.source,
+        // What the command was about — a `<Button value={id}>` that opened
+        // this popup ON that id. Handed to `onOpen` before anything is
+        // built (see open_controller.js).
+        value: e.detail?.value
       });
     },
     onnavi_request_close: e => {
@@ -30797,7 +30865,7 @@ const usePopoverProps = props => {
     // *does* (that's pointerInteractionOutsideEffect above). "auto" keeps
     // the paint the effect implies; "discrete"/"none" tone it down or
     // remove it entirely without giving up the outside click.
-    backdropAppearance = "auto",
+    backdropVariant = "auto",
     scrollCapture,
     focusCapture,
     // "auto" (default) → the popover follows its content. "frozen" → measured
@@ -30817,11 +30885,20 @@ const usePopoverProps = props => {
     // instead, so it's read here rather than left in `rest`.
     autoFocus = "last-resort",
     onKeyDown,
+    // Read here (rather than left in `rest`) for two reasons: it must never
+    // reach the DOM as an `onopen` attribute, and the controller — not this
+    // render — is what calls it, at the one moment that makes it useful (see
+    // openController.onOpen below).
+    onOpen,
     children: childrenProp,
     mountWhenClosed,
     unmountWhenClosed,
     ...rest
   } = props;
+  // Assigned on every render, like openEffect below, so it always closes over
+  // the latest prop. Called by openController.open() before the content is
+  // built: what this popup opens ON is known before anything reads it.
+  openController.onOpen = onOpen || null;
   const children = usePopupContentMount(openController, props.ref, {
     children: childrenProp,
     mountWhenClosed,
@@ -31471,7 +31548,7 @@ const usePopoverProps = props => {
     "styleCSSVars": POPUP_STYLE_CSS_VARS,
     "animationDuration": rest.animationDuration,
     "data-pointer-interaction-outside": pointerInteractionOutsideEffect,
-    "data-backdrop-appearance": backdropAppearance,
+    "data-backdrop-variant": backdropVariant,
     "onMouseDown": mouseDownEvent => {
       if (mouseDownEvent.button !== 0) {
         return;
@@ -51824,7 +51901,7 @@ const css$z = /* css */`
  *   is unavoidably *more* intrusive once it switches to dialog mode than
  *   the exact same usage would be as a popover — worth keeping in mind for
  *   anything that relies on `Popup` and can end up on a small screen.
- * @param {"auto"|"discrete"|"none"} [props.backdropAppearance] - Forwarded
+ * @param {"auto"|"discrete"|"invisible"} [props.backdropVariant] - Forwarded
  *   as-is to whichever component renders (both understand it identically):
  *   how visible the backdrop is, independently of what an outside click
  *   does. Unlike `pointerInteractionOutsideEffect` above, this one needs no
@@ -52552,7 +52629,7 @@ const PickerContentInsidePopup = props => {
     pointerInteractionOutsideEffect = "close",
     // Named/forwarded rather than left in ...rest: rest goes to the picker
     // element itself, not the popup, and this belongs to the popup.
-    backdropAppearance,
+    backdropVariant,
     dialogExpand,
     dialogExpandX,
     dialogExpandY,
@@ -52603,7 +52680,7 @@ const PickerContentInsidePopup = props => {
       marginWithContainer: marginWithContainer === undefined && isPopover ? popoverSpacing : marginWithContainer,
       scrollCapture: scrollCapture,
       pointerInteractionOutsideEffect: pointerLock ? "capture" : pointerInteractionOutsideEffect,
-      backdropAppearance: backdropAppearance,
+      backdropVariant: backdropVariant,
       focusCapture: isPopover ? focusCapture : undefined,
       expand: isPopover ? undefined : dialogExpand,
       expandX: isPopover ? undefined : dialogExpandX,
@@ -59102,6 +59179,12 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
         transparent
       );
       --picker-icon-color-disabled: var(--picker-icon-color-readonly);
+      /* Where the slots sit INSIDE the box, visible only once the box is bigger
+         than what it holds (a width/height the caller gave it). Distinct from
+         textAlign, which places the text inside the value slot; this places the
+         slots themselves. */
+      --picker-align-x-default: flex-start;
+      --picker-align-y-default: center;
     }
   }
 
@@ -59138,6 +59221,8 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
     );
     --x-picker-color: var(--picker-color);
     --x-picker-icon-color: var(--picker-icon-color);
+    --x-picker-align-x: var(--picker-align-x, var(--picker-align-x-default));
+    --x-picker-align-y: var(--picker-align-y, var(--picker-align-y-default));
 
     /* Deliberately NOT positioned: the popup children live in here, and a
        layer="local" Popover/Dialog takes its nearest positioned ancestor as
@@ -59177,7 +59262,8 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
       padding-left: 0;
       flex: 1 1 auto;
       flex-direction: row;
-      align-items: center;
+      align-items: var(--x-picker-align-y);
+      justify-content: var(--x-picker-align-x);
       background-color: var(--x-picker-background-color);
       border-width: var(--picker-border-width);
       border-style: solid;
@@ -59279,7 +59365,7 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
     }
     &[navi-single-line] {
       .navi_picker_right_slot {
-        align-self: center;
+        align-self: var(--x-picker-align-y);
       }
     }
     .navi_picker_input {
@@ -59353,14 +59439,29 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
       --x-picker-border-color: var(--callout-color);
     }
 
+    /* A variant states what the caller did NOT: it moves the DEFAULTS
+       (--picker-*) and never the resolved values (--x-picker-*), so a
+       backgroundColor/borderColor/padding prop — which lands inline on this
+       same element — still wins. The per-state defaults are re-pointed at the
+       base one too, otherwise the @layer formulas (hover = 5% black over the
+       background, disabled = 5% grey) would repaint a box the variant just
+       took away. */
     &[data-variant="icon"] {
-      --x-picker-padding-top: 0;
-      --x-picker-padding-right: 0;
-      --x-picker-padding-bottom: 0;
-      --x-picker-padding-left: 0;
+      --picker-padding-x-default: 0;
+      --picker-padding-y-default: 0;
+      /* Nothing but the icon is drawn here, so a width/height the caller gave
+         it is a target area, not a text column: the icon belongs in its middle.
+         A default, like everything else a variant moves, so alignX still wins. */
+      --picker-align-x-default: center;
       --picker-border-width: 0px; /* must carry a unit (px) — used in calc() to offset the custom input overlay */
-      --x-picker-border-color: transparent;
-      --x-picker-background-color: transparent;
+      --picker-border-color: transparent;
+      --picker-border-color-hover: var(--picker-border-color);
+      --picker-border-color-readonly: var(--picker-border-color);
+      --picker-border-color-disabled: var(--picker-border-color);
+      --picker-background-color: transparent;
+      --picker-background-color-hover: var(--picker-background-color);
+      --picker-background-color-readonly: var(--picker-background-color);
+      --picker-background-color-disabled: var(--picker-background-color);
       --x-picker-icon-color: currentColor;
     }
     /* discrete: no box at rest, a background on hover — the same word Button
@@ -59368,31 +59469,35 @@ installImportMetaCssBuild(import.meta);const css$r = /* css */`
        around it; the chevron in the right slot is what still says it opens. */
     &[data-variant="discrete"] {
       --picker-border-width: 0px; /* must carry a unit (px) — used in calc() to offset the custom input overlay */
-      --x-picker-border-color: transparent;
-      --x-picker-background-color: transparent;
-
-      &[data-hover] {
-        --x-picker-border-color: transparent;
-        --x-picker-background-color: color-mix(
-          in srgb,
-          currentColor 8%,
-          transparent
-        );
-      }
-      &[data-readonly],
-      &[data-disabled] {
-        --x-picker-border-color: transparent;
-        --x-picker-background-color: transparent;
-      }
+      --picker-border-color: transparent;
+      --picker-border-color-hover: var(--picker-border-color);
+      --picker-border-color-readonly: var(--picker-border-color);
+      --picker-border-color-disabled: var(--picker-border-color);
+      --picker-background-color: transparent;
+      /* The hover wash is mixed INTO the background instead of replacing it:
+         over the transparent default it is exactly the 8% of currentColor it
+         has always been, and over a backgroundColor the caller gave it darkens
+         that color rather than erasing it. */
+      --picker-background-color-hover: color-mix(
+        in srgb,
+        currentColor 8%,
+        var(--picker-background-color)
+      );
+      --picker-background-color-readonly: var(--picker-background-color);
+      --picker-background-color-disabled: var(--picker-background-color);
     }
     &[data-variant="headless"] {
-      --x-picker-padding-top: 0;
-      --x-picker-padding-right: 0;
-      --x-picker-padding-bottom: 0;
-      --x-picker-padding-left: 0;
+      --picker-padding-x-default: 0;
+      --picker-padding-y-default: 0;
       --picker-border-width: 0px; /* must carry a unit (px) — used in calc() to offset the custom input overlay */
-      --x-picker-border-color: transparent;
-      --x-picker-background-color: transparent;
+      --picker-border-color: transparent;
+      --picker-border-color-hover: var(--picker-border-color);
+      --picker-border-color-readonly: var(--picker-border-color);
+      --picker-border-color-disabled: var(--picker-border-color);
+      --picker-background-color: transparent;
+      --picker-background-color-hover: var(--picker-background-color);
+      --picker-background-color-readonly: var(--picker-background-color);
+      --picker-background-color-disabled: var(--picker-background-color);
       --x-picker-icon-color: currentColor;
 
       .navi_picker_box {
@@ -59449,7 +59554,15 @@ const PickerButton = props => {
   usePickerErrorCallout(uiStateController, error);
   return jsxs(Box, {
     as: "div",
-    ref: ref,
+    ref: ref
+    // The flow this element really has (.navi_picker is display:inline-flex).
+    // Left unsaid, Box reads a <div> as block and resolves alignX into a
+    // text-align — which is a different intention entirely (that one is the
+    // textAlign prop, placing the text INSIDE the value slot).
+    ,
+
+    inline: true,
+    flex: "x",
     baseClassName: "navi_picker",
     pseudoClasses: PICKER_BUTTON_PSEUDO_CLASSES,
     "data-variant": variant,
@@ -59707,6 +59820,11 @@ const PickerStyleCSSVars = {
   "popupBorderRadius": "--picker-popup-border-radius",
   "dialogBorderWidth": "--picker-dialog-border-width",
   "slotSpacing": "--picker-slot-spacing",
+  // alignX/alignY resolve to these two on a flex-x box; naming the CSS style
+  // (not the prop) is what styleCSSVars matches, so justifyContent/alignItems
+  // passed directly land in the same variables.
+  "justifyContent": "--picker-align-x",
+  "alignItems": "--picker-align-y",
   "padding": "--picker-padding",
   "paddingX": "--picker-padding-x",
   "paddingY": "--picker-padding-y",