@cueplusplus/ui 0.5.0 → 0.6.0

package/dist/chrome/status-bar.d.ts

@@ -1,4 +1,6 @@
+import { StatusBarProminence } from "./_status-bar.js";
 import * as React from "react";
+import { useRender } from "@base-ui/react/use-render";
 //#region src/chrome/status-bar.d.ts
 /**
  * Ink for a status-bar item. `neutral` inherits the bar's own subtle grey; the
@@ -19,28 +21,109 @@ interface StatusBarItemProps extends React.ComponentPropsWithoutRef<"div"> {
   push?: boolean;
   /** Optional leading icon (e.g. a lucide icon), drawn `aria-hidden`. */
   icon?: React.ElementType;
+  /**
+   * Make the item a real control: a `<button type="button">` with hover, press
+   * and keyboard-focus feedback. Defaults to `false`.
+   *
+   * A native button, not a `<div>` with an `onClick` — keyboard order is DOM
+   * order, `Enter` and `Space` work because the platform makes them work, and
+   * assistive technology is told what the thing is by the element rather than
+   * by a role attribute that has to be kept honest by hand.
+   *
+   * **An icon-only interactive item needs an `aria-label`.** There is no text
+   * for a screen reader to read and the icon is drawn `aria-hidden`, so without
+   * one the control announces as "button" and nothing else.
+   */
+  interactive?: boolean;
+  /**
+   * How loudly the item states itself. Defaults to `"quiet"`.
+   *
+   * `quiet` is a reading: tone ink on the bar's own ground. `filled` is a chip
+   * — a full-height tone wash behind tone ink — for the small set of states
+   * that earn a colour of their own: a warning, an error, the remote you are
+   * attached to. It is loud deliberately, and a bar of five filled items is a
+   * bar nobody reads.
+   */
+  prominence?: StatusBarProminence;
+  /**
+   * Replace the rendered element (Base UI render prop) — `render={<a href="…" />}`
+   * for a status item that navigates.
+   *
+   * Implies {@link StatusBarItemProps.interactive}: whatever is rendered gets
+   * the control chassis, because an element a reader can click has to look like
+   * one whether it is a button or a link.
+   */
+  render?: useRender.RenderProp;
+  /**
+   * Grey the control out, take it out of the pointer's reach and announce it as
+   * disabled. Defaults to `false`. Ignored by a static item, which is a reading
+   * and not a control.
+   *
+   * Honoured whatever {@link StatusBarItemProps.render} renders, but by two
+   * routes: the `disabled` attribute where it means something — the default
+   * `<button>`, a form control, a component that takes a `disabled` prop of its
+   * own — and `aria-disabled` plus `data-disabled` everywhere, which is all an
+   * anchor gets. There is no such thing as a disabled link; a link that should
+   * not be followed should not be a link, and this states the intent rather
+   * than pretending to enforce it.
+   */
+  disabled?: boolean;
+}
+interface StatusBarGroupProps extends React.ComponentPropsWithoutRef<"div"> {
+  /**
+   * Start the trailing cluster at this group: pushes it and everything after it
+   * to the far edge, exactly as `push` does on a single item.
+   */
+  push?: boolean;
+  /**
+   * What the cluster is called. Optional, and worth giving whenever the members
+   * only make sense together — "Repository", "Connection" — because a `group`
+   * with no name is a landmark a screen reader reads straight past.
+   */
+  "aria-label"?: string;
 }
 /**
  * The quiet strip along the bottom of a window.
  *
  * The smallest type in the system in the subtlest ink: a status bar is read
  * when you go looking for it and ignored otherwise, so it must never compete
- * with the work above it. Height comes from `--cue-chrome-statusbar`.
+ * with the work above it. Height comes from `--cue-chrome-statusbar`, and the
+ * bar clips rather than wrapping — one rung of the frame, always, whatever it
+ * is asked to hold.
+ *
+ * Items come in two kinds and the difference is deliberate. A plain
+ * `StatusBar.Item` is a **reading**: a `<div>`, inert by construction, with no
+ * hover, no focus and nothing to click — which is what most of a status bar is.
+ * `interactive` (or a `render`) makes one a **control**, and only then does it
+ * grow the button chassis, the full-height hover fill and the inset focus ring.
+ * `StatusBar.Group` fuses adjacent items into one segmented control.
  *
  * Not a live region — a status bar changes constantly (frame counters, DMX
  * output), and announcing every change would make the app unusable with a
  * screen reader. Put anything that genuinely must be announced in a `Toast`.
  *
- * Static markup — no `"use client"`.
+ * Static markup — no `"use client"`. A bar of readings renders on the server
+ * and ships no JavaScript at all; the interactive item is the one part that
+ * crosses the boundary, and it crosses it alone (`./_status-bar-item.tsx`).
  *
  * @example
  * <StatusBar>
  *   <StatusBar.Item icon={Plug} tone="ok">Art-Net connected</StatusBar.Item>
  *   <StatusBar.Item push>512 channels</StatusBar.Item>
  * </StatusBar>
+ * @example
+ * // The VS Code shape: a clickable cluster left, a loud state right.
+ * <StatusBar>
+ *   <StatusBar.Group aria-label="Repository">
+ *     <StatusBar.Item interactive icon={GitBranch}>main</StatusBar.Item>
+ *     <StatusBar.Item interactive icon={ArrowUp}>2</StatusBar.Item>
+ *   </StatusBar.Group>
+ *   <StatusBar.Item push interactive prominence="filled" tone="danger">3 faults</StatusBar.Item>
+ * </StatusBar>
  */
 declare const StatusBar: React.ForwardRefExoticComponent<Omit<React.DetailedHTMLProps<React.HTMLAttributes<HTMLDivElement>, HTMLDivElement>, "ref"> & React.RefAttributes<HTMLDivElement>> & {
-  Item: React.ForwardRefExoticComponent<StatusBarItemProps & React.RefAttributes<HTMLDivElement>>;
+  Item: React.ForwardRefExoticComponent<StatusBarItemProps & React.RefAttributes<HTMLElement>>;
+  Group: React.ForwardRefExoticComponent<StatusBarGroupProps & React.RefAttributes<HTMLDivElement>>;
 };
 //#endregion
-export { StatusBar, StatusBarItemProps, StatusBarProps, StatusBarTone };
+export { StatusBar, StatusBarGroupProps, StatusBarItemProps, type StatusBarProminence, StatusBarProps, StatusBarTone };

package/dist/chrome/status-bar.js

@@ -1,30 +1,41 @@
 import { cn } from "../lib/cn.js";
+import { STATUS_BAR_GROUP_CLASSES, statusBarItemClasses } from "./_status-bar.js";
+import { StatusBarInteractiveItem } from "./_status-bar-item.js";
 import * as React from "react";
 import { jsx, jsxs } from "react/jsx-runtime";
 //#region src/chrome/status-bar.tsx
-const ITEM_TONES = {
-	neutral: "",
-	accent: "text-accent",
-	ok: "text-ok",
-	busy: "text-busy",
-	warn: "text-warn",
-	danger: "text-danger",
-	info: "text-info"
-};
 const StatusBarRoot = React.forwardRef(function StatusBar({ className, ...elementProps }, ref) {
 	return /* @__PURE__ */ jsx("div", {
 		ref,
 		"data-slot": "status-bar",
-		className: cn("flex h-(--cue-chrome-statusbar) w-full shrink-0 items-center gap-(--cue-space-4) border-t border-border bg-surface-1 px-(--cue-pad-row-x) font-mono text-(length:--cue-text-label) text-fg-subtle", className),
+		className: cn("flex h-(--cue-chrome-statusbar) w-full shrink-0 items-center gap-(--cue-space-4) overflow-x-clip border-t border-border bg-surface-1 px-(--cue-pad-row-x) font-mono text-(length:--cue-text-label) text-fg-subtle", className),
 		...elementProps
 	});
 });
-/** One reading in the bar: a mode, a count, a connection state. */
-const StatusBarItem = React.forwardRef(function StatusBarItem({ className, tone = "neutral", push = false, icon: Icon, children, ...elementProps }, ref) {
+/**
+* One reading in the bar: a mode, a count, a connection state — or, given
+* `interactive`, one control in it.
+*/
+const StatusBarItem = React.forwardRef(function StatusBarItem({ className, tone = "neutral", push = false, icon: Icon, interactive = false, prominence = "quiet", render, disabled, children, ...elementProps }, ref) {
+	if (interactive || render !== void 0) return /* @__PURE__ */ jsx(StatusBarInteractiveItem, {
+		ref,
+		tone,
+		prominence,
+		className,
+		push,
+		icon: Icon,
+		render,
+		disabled,
+		elementProps,
+		children
+	});
 	return /* @__PURE__ */ jsxs("div", {
 		ref,
 		"data-slot": "status-bar-item",
-		className: cn("inline-flex min-w-0 shrink-0 items-center gap-(--cue-space-2) whitespace-nowrap", ITEM_TONES[tone], push ? "ml-auto" : void 0, className),
+		className: cn(statusBarItemClasses({
+			tone,
+			prominence
+		}), push ? "ml-auto" : void 0, className),
 		...elementProps,
 		children: [Icon === void 0 ? null : /* @__PURE__ */ jsx(Icon, {
 			"aria-hidden": "true",
@@ -33,24 +44,77 @@ const StatusBarItem = React.forwardRef(function StatusBarItem({ className, tone
 	});
 });
 /**
+* Items that belong to each other, one pixel apart.
+*
+* The bar spaces its readings at `--cue-space-4` because they are unrelated
+* facts. A branch name and its ahead/behind count are not unrelated facts; they
+* are one control that happens to have two halves, and the gap between them is
+* what says so. This is VS Code's `compact` mechanic — the seam collapses, and
+* hovering either half grounds both while the half under the cursor goes one
+* rung further — expressed as a wrapper rather than as an id-reference between
+* two items, because a design system's items do not have ids to point at.
+*
+* A `role="group"` rather than nothing: the members are announced as a set, and
+* the DOM order they are announced in is the order they are read in. Give it an
+* `aria-label` when the members only make sense together.
+*
+* @example
+* <StatusBar.Group aria-label="Repository">
+*   <StatusBar.Item interactive icon={GitBranch}>main</StatusBar.Item>
+*   <StatusBar.Item interactive icon={ArrowUp}>2</StatusBar.Item>
+* </StatusBar.Group>
+*/
+const StatusBarGroup = React.forwardRef(function StatusBarGroup({ className, push = false, role = "group", ...elementProps }, ref) {
+	return /* @__PURE__ */ jsx("div", {
+		ref,
+		"data-slot": "status-bar-group",
+		role,
+		className: cn(STATUS_BAR_GROUP_CLASSES, push ? "ml-auto" : void 0, className),
+		...elementProps
+	});
+});
+/**
 * The quiet strip along the bottom of a window.
 *
 * The smallest type in the system in the subtlest ink: a status bar is read
 * when you go looking for it and ignored otherwise, so it must never compete
-* with the work above it. Height comes from `--cue-chrome-statusbar`.
+* with the work above it. Height comes from `--cue-chrome-statusbar`, and the
+* bar clips rather than wrapping — one rung of the frame, always, whatever it
+* is asked to hold.
+*
+* Items come in two kinds and the difference is deliberate. A plain
+* `StatusBar.Item` is a **reading**: a `<div>`, inert by construction, with no
+* hover, no focus and nothing to click — which is what most of a status bar is.
+* `interactive` (or a `render`) makes one a **control**, and only then does it
+* grow the button chassis, the full-height hover fill and the inset focus ring.
+* `StatusBar.Group` fuses adjacent items into one segmented control.
 *
 * Not a live region — a status bar changes constantly (frame counters, DMX
 * output), and announcing every change would make the app unusable with a
 * screen reader. Put anything that genuinely must be announced in a `Toast`.
 *
-* Static markup — no `"use client"`.
+* Static markup — no `"use client"`. A bar of readings renders on the server
+* and ships no JavaScript at all; the interactive item is the one part that
+* crosses the boundary, and it crosses it alone (`./_status-bar-item.tsx`).
 *
 * @example
 * <StatusBar>
 *   <StatusBar.Item icon={Plug} tone="ok">Art-Net connected</StatusBar.Item>
 *   <StatusBar.Item push>512 channels</StatusBar.Item>
 * </StatusBar>
+* @example
+* // The VS Code shape: a clickable cluster left, a loud state right.
+* <StatusBar>
+*   <StatusBar.Group aria-label="Repository">
+*     <StatusBar.Item interactive icon={GitBranch}>main</StatusBar.Item>
+*     <StatusBar.Item interactive icon={ArrowUp}>2</StatusBar.Item>
+*   </StatusBar.Group>
+*   <StatusBar.Item push interactive prominence="filled" tone="danger">3 faults</StatusBar.Item>
+* </StatusBar>
 */
-const StatusBar = Object.assign(StatusBarRoot, { Item: StatusBarItem });
+const StatusBar = Object.assign(StatusBarRoot, {
+	Item: StatusBarItem,
+	Group: StatusBarGroup
+});
 //#endregion
 export { StatusBar };

package/dist/chrome/title-bar.d.ts

@@ -9,7 +9,17 @@ interface TitleBarProps extends React.ComponentPropsWithoutRef<"div"> {
    * the same component ships into both shells and neither one recognises the
    * other's contract. The interactive clusters are carved back out with
    * `app-region: no-drag`, or the buttons in the bar would only ever move the
-   * window instead of firing.
+   * window instead of firing. Both halves of that contract live in
+   * `./_drag.ts`, which `AppShell.Bar` emits from as well — the two bars are
+   * draggable the same way or they are not draggable the same way.
+   *
+   * Double-click-to-maximise is not wired here. Tauri's own injected script
+   * already provides it on any drag region, cancel-by-dragging-away on macOS
+   * included; Electron provides nothing, and an Electron app has to listen for
+   * `dblclick` and toggle the window itself. Neither is a decision a component
+   * in a design system can make on the window's behalf.
+   *
+   * Defaults to `false`.
    */
   platformDrag?: boolean;
   /**

package/dist/chrome/title-bar.js

@@ -1,11 +1,9 @@
 "use client";
 import { cn } from "../lib/cn.js";
+import { DRAG_CLASSES, NO_DRAG_CLASSES } from "./_drag.js";
 import * as React from "react";
 import { jsx, jsxs } from "react/jsx-runtime";
 //#region src/chrome/title-bar.tsx
-/** `app-region` needs the unprefixed and the WebKit form to cover both shells. */
-const DRAG_CLASSES = "[app-region:drag] [-webkit-app-region:drag]";
-const NO_DRAG_CLASSES = "[app-region:no-drag] [-webkit-app-region:no-drag]";
 /**
 * The window's own bar: app mark left, document name centred, controls right.
 *

package/dist/date/_segments.js

@@ -1,5 +1,5 @@
 import { cn } from "../lib/cn.js";
-import { controlVariants } from "../forms/_chassis.js";
+import { controlGroupFocusClasses, controlVariants } from "../forms/_chassis.js";
 import { ariaClassName } from "../lib/aria-class.js";
 import "react";
 import { jsx } from "react/jsx-runtime";
@@ -24,11 +24,22 @@ import { DateInput, DateSegment } from "react-aria-components";
 * The chassis lights its rim on `:focus`, which this group can never match —
 * React Aria keeps DOM focus on the individual segment and reports the group's
 * state as `data-focus-within`. Without the extra variant the inherited
-* `focus:border-accent` is a rule that cannot fire, and a segmented field is the
-* only control in the system whose rim stays dead while it is being typed into.
+* `focus:border-border-strong` is a rule that cannot fire, and a segmented field
+* would be the only control in the system whose rim stays dead while it is being
+* typed into.
+*
+* A segmented field is a grouped control in every sense that matters, so it
+* takes the grouped contract whole rather than a rim of its own invention:
+* `controlGroupFocusClasses` strengthens the rim for any focus inside and paints
+* the single flush `--cue-focus` ring only for a `:focus-visible` descendant.
+* React Aria makes each value segment `contentEditable`, and a typing surface
+* matches `:focus-visible` on a pointer click as well as on Tab, so the ring
+* lands whenever the field is actually being edited. `data-focus-within` is kept
+* beside the native `:focus-within` rim because it is the state React Aria
+* documents, and the two agree on the same colour either way.
 */
 function segmentGroupClasses(size) {
-	return cn(controlVariants({ size }), "inline-flex w-auto items-center whitespace-nowrap data-[focus-within]:border-accent");
+	return cn(controlVariants({ size }), "inline-flex w-auto items-center whitespace-nowrap data-[focus-within]:border-border-strong", controlGroupFocusClasses);
 }
 /**
 * One segment. `data-focused` — not `:focus` — carries the highlight, because

package/dist/forms/_chassis.d.ts

@@ -20,10 +20,84 @@ type FormControlSize = "sm" | "md" | "lg";
  * raising them off it, which is the portfolio-wide convention for anything the
  * user types into.
  *
+ * **Focus is one signal, not two.** The rim walks one rung up the border ladder
+ * on `:focus` — `border-border` to `border-border-strong` — and `:focus-visible`
+ * adds a single 2px outline, pulled back over that rim with
+ * `-outline-offset-1` so it sits flush against the control instead of floating
+ * a pixel clear of it. The recipe this replaced painted a saturated accent rim
+ * *and* an offset accent ring simultaneously, which in a dark, dense console
+ * reads as an error or a selection rather than as "the caret is here". No
+ * shipping system draws both: Carbon and Radix each draw one flush ring, and
+ * shadcn moved off the offset-ring default it used to ship.
+ *
+ * Flush is also the cheap way to stay correct. WCAG 2.4.13 accepts a 2px
+ * perimeter only when it touches the component's own outer edge; an indicator
+ * inset further, floating on a gap, has to be 3px thick to cover the same area.
+ * And because an outline is painted outside the layout box, none of this moves
+ * a control by a pixel or reflows the row it sits in.
+ *
+ * There is no quieter pointer path to fall back on, which is why the single
+ * treatment has to be quiet itself: every engine puts typing surfaces on the
+ * `:focus-visible` allowlist, so a text input matches it on a mouse click just
+ * as it does on Tab. Only the non-typing controls that ride this chassis — the
+ * `Select` trigger, the date triggers — actually distinguish the two.
+ *
+ * `--cue-focus`, not `--cue-accent`. Every theme ships both roles, and keeping
+ * them separable is what WCAG 1.4.11 needs: one role whose job is "read at 3:1
+ * against the surface behind the ring", independent of the role whose job is
+ * "look like the brand". Seventeen of the twenty theme blocks still set the two
+ * to the same value, so there the separation costs nothing on screen — but three
+ * light presets can no longer afford it. luma.light, venu.light and hivehub.light
+ * each read below 3:1 against surfaces a field actually sits on (luma.light as
+ * low as 2.45, and against four of its five grounds), so each now carries its
+ * own ring — the accent's hue stepped darker — while the accent itself stays
+ * put. Measured across all five grounds a field can land on — the sunken fill,
+ * the page background and the three surface rungs — every preset now clears
+ * 3:1, the thinnest being signal.light's 3.27. Pointing the ring at the focus
+ * role is what made that retune possible without repainting every accent
+ * surface in the theme.
+ *
+ * (Named in prose rather than as `--cue-*` on purpose: `tokensUsed` in the
+ * published manifest is scanned out of this file's text, so spelling the other
+ * four grounds as tokens would have every control on this chassis claim it
+ * paints a surface it never touches.)
+ *
+ * `--cue-danger` carries the same obligation on an invalid field, where it is
+ * the ring rather than only the rim — a 1.4.11 surface, not purely a semantic
+ * colour. It needed no retune: the red already clears 3:1 on all five grounds in
+ * every preset, thinnest at terminal.dark's 3.13. Both floors are held by
+ * `test/theming/contrast.test.ts`, which measures every block on every ground —
+ * the guard that was missing when these three shipped a ring nobody could see.
+ *
+ * The ring is an `outline` and never a `box-shadow`: `forced-colors: active`
+ * discards box shadows outright and repaints outlines in the user's own
+ * highlight colour, so an outline is the only indicator that survives
+ * high-contrast mode.
+ *
+ * **Invalid and focused: the ring turns red, it does not sit beside the rim.**
+ * `data-[invalid]:border-danger` does win the cascade over the focus rim, but
+ * winning it changes nothing on screen: an outline's band runs from
+ * `border-edge + offset` outward by its own width, so a 2px ring at
+ * `-outline-offset-1` spans from one pixel inside the border box to one pixel
+ * outside it — the whole 1px rim — and outlines paint after borders. Measured
+ * in both engines: an invalid control paints 456 danger pixels at rest and zero
+ * while focused. Pushing the ring off the rim would mean either floating it on
+ * a gap (WCAG 2.4.13 then wants 3px, and the halo is back) or insetting it
+ * further (which buries it deeper). So the ring takes the danger colour instead
+ * — `data-[invalid]:focus-visible:outline-danger` — which is the ruling shadcn
+ * and Radix both reached: the border stays danger, the ring communicates focus,
+ * and red communicates invalid whichever of the two is painting.
+ *
+ * The compound modifier outranks the plain one on specificity — an attribute
+ * selector and a pseudo-class against one pseudo-class — so its position in
+ * Tailwind's utility order cannot decide it. `focus-visible:outline-solid` and
+ * `focus-visible:outline-2` still supply the style and the width in both cases,
+ * which is why only the colour is restated.
+ *
  * `focus-visible:outline-solid` re-declares the outline style the sibling
  * `outline-none` switched off — see the note on `buttonChassis`.
  */
-declare const controlSurface = "w-full rounded-(--radius-control) border border-border bg-sunken font-mono text-fg placeholder:text-fg-subtle outline-none focus:border-accent focus-visible:outline-2 focus-visible:outline-solid focus-visible:outline-offset-1 focus-visible:outline-accent disabled:opacity-40 data-[disabled]:opacity-40 data-[invalid]:border-danger";
+declare const controlSurface = "w-full rounded-(--radius-control) border border-border bg-sunken font-mono text-fg placeholder:text-fg-subtle outline-none focus:border-border-strong focus-visible:outline-2 focus-visible:outline-solid focus-visible:-outline-offset-1 focus-visible:outline-(--cue-focus) disabled:opacity-40 data-[disabled]:opacity-40 data-[invalid]:border-danger data-[invalid]:focus-visible:outline-danger";
 /**
  * The full recessed-control recipe, one variant per rung of the control ladder.
  *
@@ -56,9 +130,35 @@ declare const controlClasses: string;
 declare const bareControlClasses = "min-w-0 flex-1 border-0 bg-transparent p-0 font-mono text-[length:inherit] text-fg placeholder:text-fg-subtle outline-none disabled:opacity-40";
 /**
  * Focus feedback for a wrapper that owns the rim on behalf of an inner control.
- * A `<div>` never matches `:focus-visible`, so the group has to watch its
- * descendants instead.
+ *
+ * A `<div>` never matches `:focus-visible` itself, so a group has to read the
+ * state off its descendants — and the two halves of {@link controlSurface}'s
+ * treatment want two different questions asked of them.
+ *
+ * The rim follows plain `:focus-within`: anything focused inside strengthens the
+ * border. That is the quiet half, and it is the right answer however the focus
+ * arrived. The ring follows `:has(:focus-visible)`, so it paints only when the
+ * descendant that has focus is itself showing a focus ring. Using
+ * `:focus-within` for *both* — the recipe this replaced — is what made a mouse
+ * click inside a `SearchInput` or a `NumberField` light the whole cluster up
+ * with a saturated block, the single loudest thing in a console form.
+ *
+ * `:has()` is Baseline — Chrome 105, Safari 15.4, Firefox 121 — so no
+ * `:focus-within` fallback layer is needed at the floor this library supports.
+ *
+ * Geometry matches {@link controlSurface} exactly, down to the negative offset:
+ * a grouped field and a plain one are the same control, and a rim that differed
+ * by a pixel between them would say otherwise. The inner control stays ringless
+ * — see {@link bareControlClasses} — because two concentric rings on one field
+ * is the halo this treatment exists to remove.
+ *
+ * The invalid ruling comes with the geometry, for the same reason: at
+ * `-outline-offset-1` the ring covers the rim it is drawn over, so an invalid
+ * group in focus recolours the ring rather than pretending the red under it is
+ * still visible. `data-invalid` is read off the wrapper, which is where Base
+ * UI's `Field` stamps it and where the group already takes
+ * `data-[invalid]:border-danger` from {@link controlVariants}.
  */
-declare const controlGroupFocusClasses = "focus-within:border-accent focus-within:outline-2 focus-within:outline-solid focus-within:outline-offset-1 focus-within:outline-accent";
+declare const controlGroupFocusClasses = "focus-within:border-border-strong has-focus-visible:outline-2 has-focus-visible:outline-solid has-focus-visible:-outline-offset-1 has-focus-visible:outline-(--cue-focus) data-[invalid]:has-focus-visible:outline-danger";
 //#endregion
 export { ControlVariantProps, FormControlSize, bareControlClasses, controlClasses, controlGroupFocusClasses, controlSurface, controlVariants };

package/dist/forms/_chassis.js

@@ -12,10 +12,84 @@ import { cva } from "../lib/cva.js";
 * raising them off it, which is the portfolio-wide convention for anything the
 * user types into.
 *
+* **Focus is one signal, not two.** The rim walks one rung up the border ladder
+* on `:focus` — `border-border` to `border-border-strong` — and `:focus-visible`
+* adds a single 2px outline, pulled back over that rim with
+* `-outline-offset-1` so it sits flush against the control instead of floating
+* a pixel clear of it. The recipe this replaced painted a saturated accent rim
+* *and* an offset accent ring simultaneously, which in a dark, dense console
+* reads as an error or a selection rather than as "the caret is here". No
+* shipping system draws both: Carbon and Radix each draw one flush ring, and
+* shadcn moved off the offset-ring default it used to ship.
+*
+* Flush is also the cheap way to stay correct. WCAG 2.4.13 accepts a 2px
+* perimeter only when it touches the component's own outer edge; an indicator
+* inset further, floating on a gap, has to be 3px thick to cover the same area.
+* And because an outline is painted outside the layout box, none of this moves
+* a control by a pixel or reflows the row it sits in.
+*
+* There is no quieter pointer path to fall back on, which is why the single
+* treatment has to be quiet itself: every engine puts typing surfaces on the
+* `:focus-visible` allowlist, so a text input matches it on a mouse click just
+* as it does on Tab. Only the non-typing controls that ride this chassis — the
+* `Select` trigger, the date triggers — actually distinguish the two.
+*
+* `--cue-focus`, not `--cue-accent`. Every theme ships both roles, and keeping
+* them separable is what WCAG 1.4.11 needs: one role whose job is "read at 3:1
+* against the surface behind the ring", independent of the role whose job is
+* "look like the brand". Seventeen of the twenty theme blocks still set the two
+* to the same value, so there the separation costs nothing on screen — but three
+* light presets can no longer afford it. luma.light, venu.light and hivehub.light
+* each read below 3:1 against surfaces a field actually sits on (luma.light as
+* low as 2.45, and against four of its five grounds), so each now carries its
+* own ring — the accent's hue stepped darker — while the accent itself stays
+* put. Measured across all five grounds a field can land on — the sunken fill,
+* the page background and the three surface rungs — every preset now clears
+* 3:1, the thinnest being signal.light's 3.27. Pointing the ring at the focus
+* role is what made that retune possible without repainting every accent
+* surface in the theme.
+*
+* (Named in prose rather than as `--cue-*` on purpose: `tokensUsed` in the
+* published manifest is scanned out of this file's text, so spelling the other
+* four grounds as tokens would have every control on this chassis claim it
+* paints a surface it never touches.)
+*
+* `--cue-danger` carries the same obligation on an invalid field, where it is
+* the ring rather than only the rim — a 1.4.11 surface, not purely a semantic
+* colour. It needed no retune: the red already clears 3:1 on all five grounds in
+* every preset, thinnest at terminal.dark's 3.13. Both floors are held by
+* `test/theming/contrast.test.ts`, which measures every block on every ground —
+* the guard that was missing when these three shipped a ring nobody could see.
+*
+* The ring is an `outline` and never a `box-shadow`: `forced-colors: active`
+* discards box shadows outright and repaints outlines in the user's own
+* highlight colour, so an outline is the only indicator that survives
+* high-contrast mode.
+*
+* **Invalid and focused: the ring turns red, it does not sit beside the rim.**
+* `data-[invalid]:border-danger` does win the cascade over the focus rim, but
+* winning it changes nothing on screen: an outline's band runs from
+* `border-edge + offset` outward by its own width, so a 2px ring at
+* `-outline-offset-1` spans from one pixel inside the border box to one pixel
+* outside it — the whole 1px rim — and outlines paint after borders. Measured
+* in both engines: an invalid control paints 456 danger pixels at rest and zero
+* while focused. Pushing the ring off the rim would mean either floating it on
+* a gap (WCAG 2.4.13 then wants 3px, and the halo is back) or insetting it
+* further (which buries it deeper). So the ring takes the danger colour instead
+* — `data-[invalid]:focus-visible:outline-danger` — which is the ruling shadcn
+* and Radix both reached: the border stays danger, the ring communicates focus,
+* and red communicates invalid whichever of the two is painting.
+*
+* The compound modifier outranks the plain one on specificity — an attribute
+* selector and a pseudo-class against one pseudo-class — so its position in
+* Tailwind's utility order cannot decide it. `focus-visible:outline-solid` and
+* `focus-visible:outline-2` still supply the style and the width in both cases,
+* which is why only the colour is restated.
+*
 * `focus-visible:outline-solid` re-declares the outline style the sibling
 * `outline-none` switched off — see the note on `buttonChassis`.
 */
-const controlSurface = "w-full rounded-(--radius-control) border border-border bg-sunken font-mono text-fg placeholder:text-fg-subtle outline-none focus:border-accent focus-visible:outline-2 focus-visible:outline-solid focus-visible:outline-offset-1 focus-visible:outline-accent disabled:opacity-40 data-[disabled]:opacity-40 data-[invalid]:border-danger";
+const controlSurface = "w-full rounded-(--radius-control) border border-border bg-sunken font-mono text-fg placeholder:text-fg-subtle outline-none focus:border-border-strong focus-visible:outline-2 focus-visible:outline-solid focus-visible:-outline-offset-1 focus-visible:outline-(--cue-focus) disabled:opacity-40 data-[disabled]:opacity-40 data-[invalid]:border-danger data-[invalid]:focus-visible:outline-danger";
 /**
 * The full recessed-control recipe, one variant per rung of the control ladder.
 *
@@ -51,9 +125,35 @@ const controlClasses = controlVariants();
 const bareControlClasses = "min-w-0 flex-1 border-0 bg-transparent p-0 font-mono text-[length:inherit] text-fg placeholder:text-fg-subtle outline-none disabled:opacity-40";
 /**
 * Focus feedback for a wrapper that owns the rim on behalf of an inner control.
-* A `<div>` never matches `:focus-visible`, so the group has to watch its
-* descendants instead.
+*
+* A `<div>` never matches `:focus-visible` itself, so a group has to read the
+* state off its descendants — and the two halves of {@link controlSurface}'s
+* treatment want two different questions asked of them.
+*
+* The rim follows plain `:focus-within`: anything focused inside strengthens the
+* border. That is the quiet half, and it is the right answer however the focus
+* arrived. The ring follows `:has(:focus-visible)`, so it paints only when the
+* descendant that has focus is itself showing a focus ring. Using
+* `:focus-within` for *both* — the recipe this replaced — is what made a mouse
+* click inside a `SearchInput` or a `NumberField` light the whole cluster up
+* with a saturated block, the single loudest thing in a console form.
+*
+* `:has()` is Baseline — Chrome 105, Safari 15.4, Firefox 121 — so no
+* `:focus-within` fallback layer is needed at the floor this library supports.
+*
+* Geometry matches {@link controlSurface} exactly, down to the negative offset:
+* a grouped field and a plain one are the same control, and a rim that differed
+* by a pixel between them would say otherwise. The inner control stays ringless
+* — see {@link bareControlClasses} — because two concentric rings on one field
+* is the halo this treatment exists to remove.
+*
+* The invalid ruling comes with the geometry, for the same reason: at
+* `-outline-offset-1` the ring covers the rim it is drawn over, so an invalid
+* group in focus recolours the ring rather than pretending the red under it is
+* still visible. `data-invalid` is read off the wrapper, which is where Base
+* UI's `Field` stamps it and where the group already takes
+* `data-[invalid]:border-danger` from {@link controlVariants}.
 */
-const controlGroupFocusClasses = "focus-within:border-accent focus-within:outline-2 focus-within:outline-solid focus-within:outline-offset-1 focus-within:outline-accent";
+const controlGroupFocusClasses = "focus-within:border-border-strong has-focus-visible:outline-2 has-focus-visible:outline-solid has-focus-visible:-outline-offset-1 has-focus-visible:outline-(--cue-focus) data-[invalid]:has-focus-visible:outline-danger";
 //#endregion
 export { bareControlClasses, controlClasses, controlGroupFocusClasses, controlSurface, controlVariants };

package/dist/forms/input-group.d.ts

@@ -17,9 +17,14 @@ interface InputGroupProps extends React.ComponentPropsWithoutRef<"div"> {
  * The group — not the input — owns the chassis, so there is exactly one rim and
  * one fill however many affordances are bolted on. It publishes that fact
  * through context: an {@link Input} rendered inside strips its own border,
- * background, height and padding and inherits the group's font size. Focus
- * feedback moves to `focus-within`, since a `<div>` never matches
- * `:focus-visible`.
+ * background, height and padding and inherits the group's font size.
+ *
+ * Focus feedback splits in two, because a `<div>` matches neither `:focus` nor
+ * `:focus-visible` itself. The rim strengthens on `:focus-within` — anything
+ * focused inside, however it got there — while the ring waits for
+ * `:has(:focus-visible)`, so a mouse click into the field does not light the
+ * whole cluster up. Both halves live on the wrapper; the inner control paints
+ * no ring of its own.
  *
  * @example
  * <InputGroup leading={<Search />} trailing={<Kbd>⌘K</Kbd>}>

package/dist/forms/input-group.js

@@ -17,9 +17,14 @@ const InputGroupContext = React.createContext(false);
 * The group — not the input — owns the chassis, so there is exactly one rim and
 * one fill however many affordances are bolted on. It publishes that fact
 * through context: an {@link Input} rendered inside strips its own border,
-* background, height and padding and inherits the group's font size. Focus
-* feedback moves to `focus-within`, since a `<div>` never matches
-* `:focus-visible`.
+* background, height and padding and inherits the group's font size.
+*
+* Focus feedback splits in two, because a `<div>` matches neither `:focus` nor
+* `:focus-visible` itself. The rim strengthens on `:focus-within` — anything
+* focused inside, however it got there — while the ring waits for
+* `:has(:focus-visible)`, so a mouse click into the field does not light the
+* whole cluster up. Both halves live on the wrapper; the inner control paints
+* no ring of its own.
 *
 * @example
 * <InputGroup leading={<Search />} trailing={<Kbd>⌘K</Kbd>}>

package/dist/forms/number-field.d.ts

@@ -25,8 +25,9 @@ interface NumberFieldProps extends Omit<NumberField.Root.Props, "className"> {
  * and values typed out of range are clamped to `min`/`max` on blur.
  *
  * The group owns the rim; the input and both buttons render bare inside it, so
- * the whole cluster reads as one field and focus feedback moves to
- * `focus-within`.
+ * the whole cluster reads as one field. Focus feedback follows the group's
+ * split: the rim strengthens on `:focus-within`, and the ring waits for
+ * `:has(:focus-visible)` so a click on a stepper does not paint one.
  *
  * @example
  * <NumberField aria-label="Fade time" defaultValue={3} min={0} max={600} step={0.5} />

package/dist/forms/number-field.js

@@ -17,8 +17,9 @@ const stepperClasses = "flex shrink-0 items-center justify-center border-0 bg-tr
 * and values typed out of range are clamped to `min`/`max` on blur.
 *
 * The group owns the rim; the input and both buttons render bare inside it, so
-* the whole cluster reads as one field and focus feedback moves to
-* `focus-within`.
+* the whole cluster reads as one field. Focus feedback follows the group's
+* split: the rim strengthens on `:focus-within`, and the ring waits for
+* `:has(:focus-visible)` so a click on a stepper does not paint one.
 *
 * @example
 * <NumberField aria-label="Fade time" defaultValue={3} min={0} max={600} step={0.5} />