@junoput01/junoui 0.7.0 → 0.9.0

package/dist/css/juno.css

@@ -21,6 +21,16 @@
   --juno-shadow-1: 0 1px 2px rgb(0 0 0 / 0.30);
   --juno-shadow-2: 0 4px 14px rgb(0 0 0 / 0.35);
   --juno-shadow-3: 0 12px 32px rgb(0 0 0 / 0.50);
+  --juno-ink-canvas-ink: #FFFFFF;
+  --juno-ink-canvas-halo: #000000;
+  --juno-ink-canvas-halo-width: 2px;
+  --juno-ink-canvas-halo-width-lg: 3px;
+  --juno-ink-canvas-scrim: 0.28;
+  --juno-ink-vivid-nominal: oklch(76% 0.28 148);
+  --juno-ink-vivid-active: oklch(76% 0.24 205);
+  --juno-ink-vivid-target: oklch(70% 0.30 328);
+  --juno-ink-vivid-caution: oklch(82% 0.20 82);
+  --juno-ink-vivid-warning: oklch(68% 0.28 25);
   --juno-motion-duration-instant: 80ms;
   --juno-motion-duration-quick: 140ms;
   --juno-motion-duration-base: 200ms;
@@ -540,47 +550,18 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
      `.juno-input` font-size later in the bundle. It did, silently, until
      20260815-006's coarse-pointer project measured it. */
 
-  /* Kill the UA tap-highlight square on the interactive surfaces so it never
-     flashes past a rounded control on tap. Consumers were adding this by hand
-     per component; make it a first-class touch default. See 20260802-020. */
-  :where(
-    .juno-btn,
-    .juno-dock__item,
-    .juno-pillbar__item,
-    .juno-tabs__tab,
-    .juno-list__row,
-    .juno-menu__item
-  ) {
-    -webkit-tap-highlight-color: transparent;
-  }
+  /* The tap-highlight default that used to live here is GENERATED now, from
+     src/css/touch-surfaces.mjs, together with the touch-action default that
+     shares its member list. Two hand-maintained lists had drifted from the
+     classes and from each other; see that file. */
 }
 
-/* Tappable primitives opt out of double-tap-to-zoom. A browser that still
-   recognises that gesture has to WAIT after the first tap to see whether a
-   second one is coming, which reads as a late, mushy tap on exactly the
-   surfaces a phone UI is built from. `manipulation` keeps panning and
-   pinch-zoom (so the page stays zoomable — never `none` here, that would be an
-   a11y regression) and drops only the double-tap.
-   NOT inside the pointer:coarse block above: a hybrid device (touch laptop,
-   iPad with a trackpad) reports a fine primary pointer while still taking
-   touch input, and the property is inert on a mouse anyway.
-   Community convention — no primary Apple/WebKit source names it; see
-   docs/ios-conformance.md. Named components only, so a consumer's own elements
-   are untouched. See 20260803-038. */
-:where(
-  .juno-btn,
-  .juno-dock__item,
-  .juno-pillbar__item,
-  .juno-pillbar__overflow,
-  .juno-tabs__tab,
-  .juno-list__row,
-  .juno-menu__item,
-  .juno-seg__opt,
-  .juno-chip,
-  .juno-toggle-btn
-) {
-  touch-action: manipulation;
-}
+/* The touch defaults that used to be two hand-maintained `:where()` lists here
+   are GENERATED from src/css/touch-surfaces.mjs and emitted straight after this
+   file. Both lists had drifted — from the classes (`.juno-seg__option`,
+   `.juno-list__item`: neither exists, so `:where()` matched nothing and the
+   rule parsed anyway) and from each other. One declared set now feeds both.
+   See 20260826-024 and docs/conformance-kit.md. */
 
 /* Gesture-owned surfaces — for an element whose pointer events are fully
    driven by app JS (drag-pan, pinch-zoom, swipe classification: a state
@@ -720,6 +701,62 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
   .juno-tooltip__bubble[popover] { display: none; }
 }
 
+/* GENERATED from src/css/touch-surfaces.mjs — do not edit here.
+ *
+ * Tappable primitives opt out of double-tap-to-zoom. A browser that still
+ * recognises that gesture has to WAIT after the first tap to see whether a
+ * second one is coming, which reads as a late, mushy tap on exactly the
+ * surfaces a phone UI is built from. `manipulation` keeps panning and
+ * pinch-zoom (so the page stays zoomable — never `none` here, that would be an
+ * a11y regression) and drops only the double-tap.
+ * Community convention — no primary Apple/WebKit source names it; see
+ * docs/ios-conformance.md. Named components only, so a consumer's own elements
+ * are untouched. See 20260803-038. */
+:where(
+  .juno-btn,
+  .juno-chip,
+  .juno-dock__item,
+  .juno-list__row,
+  .juno-menu__item,
+  .juno-pillbar__item,
+  .juno-pillbar__overflow,
+  .juno-seg__opt,
+  .juno-tabs__tab,
+  .juno-toggle-btn,
+  .juno-tree__row,
+  .juno-gizmo__mark,
+  .juno-gizmo__center,
+  .juno-swatch--button,
+  .juno-palette__option
+) {
+  touch-action: manipulation;
+}
+
+/* And on touch, kill the UA tap-highlight square so it never flashes past a
+ * rounded control. Consumers were adding this by hand per component; it is a
+ * first-class touch default. See 20260802-020. */
+@media (pointer: coarse) {
+:where(
+    .juno-btn,
+    .juno-chip,
+    .juno-dock__item,
+    .juno-list__row,
+    .juno-menu__item,
+    .juno-pillbar__item,
+    .juno-pillbar__overflow,
+    .juno-seg__opt,
+    .juno-tabs__tab,
+    .juno-toggle-btn,
+    .juno-tree__row,
+    .juno-gizmo__mark,
+    .juno-gizmo__center,
+    .juno-swatch--button,
+    .juno-palette__option
+  ) {
+    -webkit-tap-highlight-color: transparent;
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  junoui — layout layer (intrinsic & responsive)
  *
@@ -1480,6 +1517,104 @@ details.juno-accordion__item:only-child {
   filter: none;
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Canvas ink (marks drawn over arbitrary imagery)
+ *  For text and vector ink sitting on a photo, a map, a video frame or a
+ *  camera feed: anywhere the background is CONTENT rather than one of
+ *  junoui's surfaces.
+ *
+ *  WHY IT IS NOT JUST A COLOUR. junoui's whole contrast story assumes a
+ *  controlled surface, s0 through s3 — every role colour's ratio is
+ *  computed against a known background. Over imagery there is no known
+ *  background. In one orthophoto a black shadow and a snowfield are
+ *  adjacent pixels, so no single ink colour is legible and no contrast
+ *  ratio can be asserted about one. The answer is a PAIR that spans the
+ *  luminance range: over a light backing the halo carries the contrast,
+ *  over a dark one the ink does. Neither half works alone, which is why
+ *  they are applied together by one class.
+ *
+ *  NOT THEMED, on purpose. A satellite image does not get lighter because
+ *  the user chose light mode. Theming this pair would make it track the
+ *  app's surface, which is precisely the background it is NOT over.
+ *  Usage:
+ *    <figcaption class="juno-canvas-ink">Sector 7 · 1.2 km</figcaption>
+ *    <svg class="juno-canvas-ink"><path class="juno-canvas-ink__stroke" …/></svg>
+ *    <div class="juno-canvas-scrim">…chrome floating over the content…</div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+/* Text. Four offset shadows rather than one blur: a blurred shadow fades at
+   the glyph's corners, which is exactly where a thin stroke needs the most
+   help, and it costs the same. `paint-order` is for SVG text, where a real
+   stroke is available and better. */
+.juno-canvas-ink {
+  color: var(--juno-ink-canvas-ink);
+  paint-order: stroke fill;
+  stroke: var(--juno-ink-canvas-halo);
+  stroke-width: var(--juno-ink-canvas-halo-width);
+  text-shadow:
+    var(--juno-ink-canvas-halo-width) 0 0 var(--juno-ink-canvas-halo),
+    calc(-1 * var(--juno-ink-canvas-halo-width)) 0 0 var(--juno-ink-canvas-halo),
+    0 var(--juno-ink-canvas-halo-width) 0 var(--juno-ink-canvas-halo),
+    0 calc(-1 * var(--juno-ink-canvas-halo-width)) 0 var(--juno-ink-canvas-halo);
+}
+
+/* Display sizes: a 2px halo reads as a hairline against a heavier stroke. */
+.juno-canvas-ink--lg {
+  stroke-width: var(--juno-ink-canvas-halo-width-lg);
+  text-shadow:
+    var(--juno-ink-canvas-halo-width-lg) 0 0 var(--juno-ink-canvas-halo),
+    calc(-1 * var(--juno-ink-canvas-halo-width-lg)) 0 0 var(--juno-ink-canvas-halo),
+    0 var(--juno-ink-canvas-halo-width-lg) 0 var(--juno-ink-canvas-halo),
+    0 calc(-1 * var(--juno-ink-canvas-halo-width-lg)) 0 var(--juno-ink-canvas-halo);
+}
+
+/* Vector ink — measurement lines, selection outlines. Two passes: the halo
+   is the same path drawn wider underneath. In SVG give the halo element
+   this class and the mark element __stroke; in canvas, stroke twice. */
+.juno-canvas-ink__halo {
+  fill: none;
+  stroke: var(--juno-ink-canvas-halo);
+  stroke-width: calc(var(--juno-ink-canvas-halo-width) * 2);
+  stroke-linecap: round;
+  stroke-linejoin: round;
+}
+
+.juno-canvas-ink__stroke {
+  fill: none;
+  stroke: var(--juno-ink-canvas-ink);
+  stroke-linecap: round;
+  stroke-linejoin: round;
+}
+
+/* Status over canvas. The themed role hues are chosen against s0–s3 and wash
+   out over a saturated backdrop, so these are the same hues at raised chroma.
+   Louder than the panel roles by design — they will look wrong on a panel. */
+.juno-canvas-ink--nominal { color: var(--juno-ink-vivid-nominal); }
+.juno-canvas-ink--active { color: var(--juno-ink-vivid-active); }
+.juno-canvas-ink--target { color: var(--juno-ink-vivid-target); }
+.juno-canvas-ink--caution { color: var(--juno-ink-vivid-caution); }
+.juno-canvas-ink--warning { color: var(--juno-ink-vivid-warning); }
+
+/* Chrome floating over live content. Deliberately NOT --juno-opacity-scrim
+   (0.62): that value suppresses a modal's background, and here the background
+   is the thing the chrome is annotating — greying it out defeats the purpose. */
+.juno-canvas-scrim {
+  background: color-mix(in srgb, var(--juno-s0) calc(var(--juno-ink-canvas-scrim) * 100%), transparent);
+  -webkit-backdrop-filter: blur(8px);
+  backdrop-filter: blur(8px);
+}
+
+/* A translucent bar over moving content is the case where reduced
+   transparency matters most — the motion behind the text is the problem, not
+   the blur. Fall back to the opaque surface. */
+@media (prefers-reduced-transparency: reduce) {
+  .juno-canvas-scrim {
+    background: var(--juno-s0);
+    -webkit-backdrop-filter: none;
+    backdrop-filter: none;
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Card / panel
  *  Usage:
@@ -2611,6 +2746,245 @@ button.juno-chip {
 }
 .juno-gauge--lg .juno-gauge__value { font-size: var(--juno-font-size-20); }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Viewport orientation gizmo (compass ring + pitch arc)
+ *  The orientation widget any 3D or map viewport ships: a ring showing a
+ *  heading with clickable snap targets, a secondary arc for a second
+ *  angle (pitch / tilt / elevation) inside a clamped range, and a centre
+ *  target that resets the view.
+ *
+ *  A RING, NOT A CUBE, and that is a design decision rather than a style
+ *  one. An Autodesk-style ViewCube is the wrong shape for anything with a
+ *  privileged up-vector — a map, a terrain, a site plan — because there is
+ *  no meaningful front, right or bottom face to click. A ring degrades to
+ *  the up-vector case and generalises to the free-orbit one; a cube does
+ *  not go the other way.
+ *
+ *  THE APP OWNS THE CAMERA. It writes two angles in as custom properties
+ *  and junoui rotates the marks; nothing here stores or changes state.
+ *    element.style.setProperty('--juno-gizmo-heading', `${yaw}deg`);
+ *    element.style.setProperty('--juno-gizmo-pitch', `${pitch}deg`);
+ *
+ *  Usage — see docs/components/gizmo.md for the full a11y contract, which
+ *  is the half apps get wrong and the reason this is upstream:
+ *    <div class="juno-gizmo" role="group" aria-label="View orientation">
+ *      <p class="juno-gizmo__readout" aria-live="polite">Facing north, 0 degrees.</p>
+ *      <div class="juno-gizmo__ring">
+ *        <span class="juno-gizmo__needle" aria-hidden="true"></span>
+ *        <button class="juno-gizmo__mark" style="--juno-gizmo-at:0deg"
+ *                aria-label="Face north" aria-current="true">N</button>
+ *        …seven more…
+ *        <button class="juno-gizmo__center" aria-label="Reset view">⌖</button>
+ *      </div>
+ *      <div class="juno-gizmo__arc">
+ *        <span class="juno-gizmo__arc-hand" aria-hidden="true"></span>
+ *      </div>
+ *    </div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-gizmo {
+  --juno-role: var(--juno-active);
+
+  /* The angles the app writes. Defaults are a level view facing north, so a
+     gizmo that is mounted before the camera reports is not a blank circle. */
+  --juno-gizmo-heading: 0deg;
+  --juno-gizmo-pitch: 0deg;
+
+  /* MINIMUM DIAMETER, DERIVED — and derived from the CHORD, which is the
+     correction that matters. N marks sit evenly around the rim, so the
+     straight-line distance between two adjacent centres is d * sin(pi / N).
+     For their targets not to overlap THAT must be at least one tap target:
+
+         d >= tap / sin(pi / N)
+
+     ...and the marks sit INSIDE the rim, so their centres are on a circle of
+     radius d/2 - tap/2, not d/2. Substituting that and solving:
+
+         d >= tap * (1 / sin(pi / N) + 1)
+
+     THIS DERIVATION WAS WRONG TWICE, and the browser guard caught both. First
+     it sized off the ARC between centres (N * tap / pi) — an arc is longer
+     than its chord, so at N=8 and a 44px target that gave 112.05px whose chord
+     is 42.9px, a 1.1px overlap on every neighbouring pair. Corrected to the
+     chord, it still measured 27.16px between centres, because the inset had
+     been left out of the radius. Neither error is visible in the source; both
+     are one measurement away.
+
+     The tap floor MOVES, 24px to 44px on a coarse pointer, which is precisely
+     when the ring has to grow; a hard-coded diameter ships eight overlapping
+     targets to a phone. The 96px is an aesthetic floor, not a derived one —
+     a 63px ring is legible-but-cramped on desktop — and max() keeps whichever
+     is larger. */
+  --juno-gizmo-marks: 8;
+  --juno-gizmo-size: max(
+    96px,
+    calc(var(--juno-size-tap-min) * (1 / sin(180deg / var(--juno-gizmo-marks)) + 1))
+  );
+
+  display: inline-flex;
+  flex-direction: column;
+  align-items: center;
+  gap: var(--juno-space-8);
+  font-family: var(--juno-font-family-sans);
+  color: var(--juno-data);
+}
+
+/* The spoken state. Visible by default — a bearing is useful to everyone —
+   but it is the live region either way, because a rotating needle announces
+   nothing. Consumers that want it invisible use .juno-sr-only rather than
+   display:none, which would take it out of the accessibility tree too. */
+.juno-gizmo__readout {
+  margin: 0;
+  font-size: var(--juno-font-size-11);
+  font-variant-numeric: tabular-nums;
+  letter-spacing: var(--juno-font-tracking-label);
+  color: var(--juno-label);
+}
+
+.juno-gizmo__ring {
+  position: relative;
+  inline-size: var(--juno-gizmo-size);
+  block-size: var(--juno-gizmo-size);
+  border-radius: 50%;
+  border: var(--juno-border-width-1) solid var(--juno-border);
+  background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
+}
+
+/* The needle points where the camera looks. Rotated by the app's angle, and
+   the transition runs on the motion scale so prefers-reduced-motion collapses
+   it without this file needing its own media query (base.css owns that). */
+.juno-gizmo__needle {
+  position: absolute;
+  inset: 0;
+  display: grid;
+  place-items: start center;
+  pointer-events: none;
+  rotate: var(--juno-gizmo-heading);
+  transition: rotate calc(var(--juno-motion-duration-base) * var(--juno-motion-scale))
+    var(--juno-motion-ease-standard);
+}
+
+.juno-gizmo__needle::before {
+  content: '';
+  inline-size: var(--juno-border-width-2);
+  block-size: 38%;
+  margin-block-start: var(--juno-space-4);
+  background: linear-gradient(var(--juno-role), transparent);
+  border-radius: var(--juno-border-width-2);
+}
+
+/* ── snap targets ──────────────────────────────────────────────────────
+   REAL BUTTONS. Not a canvas hit test, not a div with a click handler: a
+   button is focusable, activates on Enter and Space, is announced as a
+   control, and works with a screen reader's forms mode. That is most of
+   this component's value and the reason it is upstream.
+
+   Positioned by rotating the mark out to the rim and counter-rotating the
+   glyph, so the letter stays upright at every angle. --juno-gizmo-at is the
+   mark's own bearing, set per element. */
+.juno-gizmo__mark {
+  position: absolute;
+  inset-block-start: 50%;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-size-tap-min);
+  block-size: var(--juno-size-tap-min);
+  margin: calc(var(--juno-size-tap-min) / -2);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  border-radius: 50%;
+  background: transparent;
+  color: var(--juno-label);
+  font: inherit;
+  font-size: var(--juno-font-size-11);
+  font-weight: var(--juno-font-weight-bold);
+  cursor: pointer;
+  transform: rotate(var(--juno-gizmo-at, 0deg))
+    translate(0, calc(var(--juno-gizmo-size) / -2 + var(--juno-size-tap-min) / 2))
+    rotate(calc(-1 * var(--juno-gizmo-at, 0deg)));
+}
+
+.juno-gizmo__mark:hover {
+  color: var(--juno-data);
+  background: var(--juno-s2);
+}
+
+/* The mark the camera is currently nearest. aria-current, not a class: the
+   app already has to say it for the screen reader, and a class would be a
+   second copy of the same fact. */
+.juno-gizmo__mark[aria-current='true'] {
+  color: var(--juno-role);
+  background: var(--juno-s3);
+}
+
+.juno-gizmo__mark:focus-visible,
+.juno-gizmo__center:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: var(--juno-space-2);
+}
+
+/* Centre target — reset to the default view. */
+.juno-gizmo__center {
+  position: absolute;
+  inset-block-start: 50%;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-size-tap-min);
+  block-size: var(--juno-size-tap-min);
+  margin: calc(var(--juno-size-tap-min) / -2);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: var(--juno-border-width-1) solid var(--juno-border);
+  border-radius: 50%;
+  background: var(--juno-s1);
+  color: var(--juno-label);
+  font: inherit;
+  cursor: pointer;
+}
+
+.juno-gizmo__center:hover {
+  color: var(--juno-role);
+  border-color: var(--juno-role);
+}
+
+/* ── pitch arc ─────────────────────────────────────────────────────────
+   The second angle, inside a CLAMPED range — a camera that can tilt 0..85°
+   should not show a hand that can point anywhere, or the widget lies about
+   what the app will accept. The clamp lives here so every consumer gets it
+   without re-deriving it from its own camera limits. */
+.juno-gizmo__arc {
+  --juno-gizmo-pitch-min: 0deg;
+  --juno-gizmo-pitch-max: 85deg;
+
+  position: relative;
+  inline-size: var(--juno-gizmo-size);
+  block-size: calc(var(--juno-gizmo-size) / 2);
+  overflow: hidden;
+  border-block-end: var(--juno-border-width-1) solid var(--juno-border);
+}
+
+.juno-gizmo__arc-hand {
+  position: absolute;
+  inset-block-end: 0;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-border-width-2);
+  block-size: 80%;
+  background: var(--juno-role);
+  transform-origin: bottom center;
+  rotate: clamp(var(--juno-gizmo-pitch-min), var(--juno-gizmo-pitch), var(--juno-gizmo-pitch-max));
+  transition: rotate calc(var(--juno-motion-duration-base) * var(--juno-motion-scale))
+    var(--juno-motion-ease-standard);
+}
+
+/* ── touch ─────────────────────────────────────────────────────────────
+   Nothing to grow here, and that is the point: the marks are sized in
+   --juno-size-tap-min, which base.css promotes to the comfortable target on a
+   coarse pointer, and --juno-gizmo-size is derived from it — so the whole ring
+   grows and the marks stay non-overlapping by construction. A gizmo that keeps
+   its desktop diameter on a phone has eight overlapping targets, which is the
+   defect this derivation exists to make impossible. */
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Icon loader (the ring-a-control primitive)
  *  A control ringed by the spinning arc while its section loads — the
@@ -4823,6 +5197,194 @@ button.juno-seg__opt:disabled {
   block-size: 100%;
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Colour swatch + palette
+ *  Showing a user-chosen colour, and letting someone pick one. Diagrams,
+ *  calendars, tag and label systems, chart series colours, annotation
+ *  tools, theming UIs, kanban boards.
+ *
+ *  THE HARD PART IS NOT THE SQUARE. A swatch shows an ARBITRARY colour, so
+ *  every piece of chrome on it — its border, its focus ring, its checked
+ *  indicator — has to stay visible against a colour junoui has never seen.
+ *  A single hairline fails at one end of the range: a dark border vanishes
+ *  on near-black, a light one vanishes on near-white, and the swatch that
+ *  loses its border is the one that has merged with the panel behind it.
+ *
+ *  The answer is a PAIR of hairlines drawn as an inset and an outset ring.
+ *  They do NOT do the same job, which is the part worth reading twice: the
+ *  inset one composites over the SWATCH and edges it against its own fill,
+ *  the outset one composites over the PANEL and separates it from the
+ *  surface. With the swatch's own contrast against that panel, the boundary
+ *  has three ways to be visible and needs only one of them.
+ *
+ *  Guarded by sweeping the swatch colour against both panels rather than by
+ *  asserting a border value (test/swatch.test.mjs).
+ *
+ *  COLOUR IS NEVER THE ONLY SIGNAL. junoui's own standing rule, and a bare
+ *  swatch is exactly what violates it: every swatch carries an accessible
+ *  NAME, and the checked state carries a GLYPH, not just a hue.
+ *
+ *  The app owns the colour list and which one is chosen.
+ *  Usage:
+ *    <button class="juno-swatch juno-swatch--button" style="--juno-swatch-color:#C41E3A"
+ *            aria-label="Crimson"></button>
+ *
+ *    <div class="juno-popover" popover id="palette">
+ *      <div class="juno-palette" role="listbox" aria-label="Annotation colour">
+ *        <button class="juno-palette__option" role="option" aria-selected="true"
+ *                style="--juno-swatch-color:#C41E3A" aria-label="Crimson">
+ *          <svg class="juno-icon juno-palette__check" aria-hidden="true">
+ *            <use href="…#juno-i-check" /></svg>
+ *        </button>
+ *      </div>
+ *    </div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-swatch {
+  /* The colour the app is showing. Named rather than an inline `background`
+     so the rings below can sit on top of it without the caller reassembling
+     the whole box-shadow stack. */
+  --juno-swatch-color: var(--juno-muted);
+
+  /* Sized off the control scale, so a swatch in a form row matches the
+     controls beside it and grows with them on a coarse pointer. */
+  --juno-swatch-size: var(--juno-size-tap-min);
+
+  display: inline-block;
+  inline-size: var(--juno-swatch-size);
+  block-size: var(--juno-swatch-size);
+  flex-shrink: 0;
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: var(--juno-swatch-color);
+
+  /* THE TWO-TONE RING, and the alphas are measured rather than chosen.
+     The inset ring composites over the SWATCH and gives it an edge against
+     its own fill; the outset ring composites over the PANEL — an outset
+     box-shadow is outside the element — and separates the swatch from the
+     surface behind it. Between them, plus the swatch's own contrast with the
+     panel, the boundary is discernible whatever colour the app supplies.
+
+     At 0.45 / 0.35 that property FAILS: on a light panel a mid-grey swatch
+     (around #919191) leaves the best of the three at 2.57:1, under the 3:1
+     non-text floor. 0.65 on both takes the worst case to 3.39:1. The sweep in
+     test/swatch.test.mjs is what measured it — the first version of that test
+     asked the wrong question (both rings against the swatch) and reported 145
+     failures; the right question is whether the BOUNDARY is visible, and it
+     has three ways to be.
+
+     Deliberately not `border`, which would eat into the colour area and change
+     the swatch's size with its style. */
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65);
+}
+
+.juno-swatch--circle {
+  border-radius: 50%;
+}
+
+.juno-swatch--sm {
+  --juno-swatch-size: var(--juno-space-16);
+}
+
+.juno-swatch--lg {
+  --juno-swatch-size: var(--juno-size-tap-comfortable);
+}
+
+/* A swatch used as a trigger — the thing you click to open the palette. */
+.juno-swatch--button {
+  padding: 0;
+  cursor: pointer;
+}
+
+/* FOCUS RINGS ON AN ARBITRARY HUE. The ring is drawn OUTSIDE the swatch,
+   with an offset, so its contrast is against the panel — a known surface —
+   rather than against a colour junoui cannot predict. A ring drawn on the
+   swatch itself has the same unsolvable problem as the border, and "use a
+   thicker ring" does not fix a hue collision. */
+.juno-swatch--button:focus-visible,
+.juno-palette__option:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: var(--juno-space-4);
+}
+
+/* ── palette ───────────────────────────────────────────────────────────
+   A grid of swatches inside a .juno-popover. junoui ships the grid and the
+   states; the app owns the list and which one is chosen. */
+.juno-palette {
+  display: grid;
+  grid-template-columns: repeat(var(--juno-palette-columns, 6), auto);
+  gap: var(--juno-space-8);
+  padding: var(--juno-space-4);
+}
+
+.juno-palette__option {
+  --juno-swatch-color: var(--juno-muted);
+  --juno-swatch-size: var(--juno-size-tap-min);
+
+  position: relative;
+  inline-size: var(--juno-swatch-size);
+  block-size: var(--juno-swatch-size);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: var(--juno-swatch-color);
+  cursor: pointer;
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65);
+}
+
+/* THE CHECKED STATE IS A GLYPH, NOT A HUE. Colour is never the only signal,
+   and "the chosen one is the one that looks slightly different" is exactly
+   the failure that rule exists to prevent — it is invisible to anyone who
+   cannot separate the two hues, and to anyone looking at a screenshot.
+
+   The check itself sits on the arbitrary colour, so it gets the same
+   treatment as the swatch's own ring: a light glyph with a dark halo, which
+   is the canvas-ink pair at glyph scale. */
+.juno-palette__check {
+  display: none;
+  color: #fff;
+  filter: drop-shadow(0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.9))
+    drop-shadow(0 0 var(--juno-border-width-2) rgb(0 0 0 / 0.7));
+}
+
+.juno-palette__option[aria-selected='true'] .juno-palette__check,
+.juno-palette__option[aria-checked='true'] .juno-palette__check {
+  display: block;
+}
+
+/* ...and a second, non-glyph cue for the same state, because a check inside a
+   28px square is small: the selected option also grows a ring in the active
+   role, drawn OUTSIDE the swatch where its contrast is against the panel. */
+.juno-palette__option[aria-selected='true'],
+.juno-palette__option[aria-checked='true'] {
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65),
+    0 0 0 calc(var(--juno-border-width-1) + var(--juno-border-width-2)) var(--juno-active);
+}
+
+/* A swatch showing "no colour" — transparent, unset, inherit. Without this a
+   consumer paints it in a mid grey and the user cannot tell "grey" from
+   "none", which is a different thing to know. */
+.juno-swatch--none,
+.juno-palette__option--none {
+  background:
+    linear-gradient(
+        to bottom right,
+        transparent calc(50% - var(--juno-border-width-1)),
+        var(--juno-warning) calc(50% - var(--juno-border-width-1)),
+        var(--juno-warning) calc(50% + var(--juno-border-width-1)),
+        transparent calc(50% + var(--juno-border-width-1))
+      )
+      var(--juno-s1);
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Switch (toggle)  ·  labeled rocker
  *  A wide squared slide-switch with the state printed inside the track
@@ -5965,6 +6527,266 @@ button.juno-seg__opt:disabled {
   inset-inline-start: calc(100% - var(--juno-space-4));
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Tree / outliner (nested rows, disclosure, selection)
+ *  Layer stacks, file browsers, settings trees, org charts, comment
+ *  threads, nested navigation. Where .juno-list is flat and
+ *  .juno-accordion is single-level, this nests to arbitrary depth and
+ *  carries a selection.
+ *
+ *  ZERO JS FOR THE VISUALS. Indentation comes from the nested `role=group`
+ *  lists the ARIA pattern already requires, so depth costs no custom
+ *  property and no inline style; collapse is `[aria-expanded='false']`
+ *  hiding the child group. The app owns the attribute, exactly like
+ *  __item's aria-pressed elsewhere in junoui.
+ *
+ *  KEYBOARD IS NOT OPTIONAL and is not CSS. A tree without arrow-key
+ *  traversal and a roving tabindex is a list of buttons wearing tree
+ *  roles. junoui ships the contract in docs/components/tree.md and a
+ *  stateless enhancer at `junoui/tree` — use one or the other, but a tree
+ *  that has neither is not accessible and no stylesheet can fix it.
+ *
+ *  Usage (the markup the roles require — see the doc for the full ARIA
+ *  contract, which is the half apps get wrong):
+ *    <ul class="juno-tree" role="tree" aria-label="Scene">
+ *      <li class="juno-tree__item" role="treeitem" aria-level="1"
+ *          aria-expanded="true" aria-selected="false">
+ *        <div class="juno-tree__row">
+ *          <button class="juno-tree__caret" tabindex="-1" aria-hidden="true"></button>
+ *          <svg class="juno-icon juno-tree__icon" aria-hidden="true">…</svg>
+ *          <span class="juno-tree__label">Terrain</span>
+ *          <span class="juno-tree__count">12</span>
+ *          <span class="juno-tree__trail">…</span>
+ *          <button class="juno-tree__handle" aria-label="Reorder Terrain"></button>
+ *        </div>
+ *        <ul class="juno-tree__group" role="group">…</ul>
+ *      </li>
+ *    </ul>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-tree {
+  --juno-role: var(--juno-active);
+
+  /* One indent step. Applied per nested group, so depth is structural and
+     arbitrary rather than a level number someone has to keep in sync. */
+  --juno-tree-indent: var(--juno-space-16);
+
+  margin: 0;
+  padding: 0;
+  list-style: none;
+  font-family: var(--juno-font-family-sans);
+  font-size: var(--juno-font-size-13);
+  color: var(--juno-data);
+}
+
+.juno-tree__group {
+  margin: 0;
+  padding: 0;
+  padding-inline-start: var(--juno-tree-indent);
+  list-style: none;
+}
+
+/* Collapsed: the child group goes. `display: none` and not a height
+   animation — a tree collapses an unknown number of rows at an unknown
+   depth, so there is no end value to transition to, and interpolate-size
+   is not available everywhere junoui targets. */
+.juno-tree__item[aria-expanded='false'] > .juno-tree__group {
+  display: none;
+}
+
+.juno-tree__row {
+  display: flex;
+  align-items: center;
+  gap: var(--juno-space-8);
+  inline-size: 100%;
+  min-block-size: var(--juno-size-tap-min);
+  padding-inline: var(--juno-space-8);
+  padding-block: var(--juno-space-4);
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: transparent;
+  color: inherit;
+  font: inherit;
+  text-align: start;
+  text-decoration: none;
+  cursor: pointer;
+}
+
+.juno-tree__row:hover {
+  background: var(--juno-s2);
+}
+
+/* SELECTION is a different fact from hover and from aria-current, and the
+   ticket is right that conflating them is the common bug: hover is where the
+   pointer is, aria-current is which page you are on, aria-selected is what
+   the next action will apply to. A layer stack has all three at once. */
+.juno-tree__item[aria-selected='true'] > .juno-tree__row {
+  background: var(--juno-s3);
+  color: var(--juno-role);
+}
+
+.juno-tree__item[aria-current] > .juno-tree__row {
+  box-shadow: inset var(--juno-border-width-2) 0 0 var(--juno-role);
+}
+
+.juno-tree__row:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: calc(-1 * var(--juno-border-width-2));
+}
+
+/* ── disclosure caret ──────────────────────────────────────────────────
+   aria-hidden and tabindex=-1 on purpose: the row itself is the treeitem
+   and Left/Right already collapse and expand, so a separately focusable
+   caret puts a second stop in the tab order for an action the row has. It
+   stays a real button for the pointer. */
+.juno-tree__caret {
+  flex-shrink: 0;
+  inline-size: var(--juno-space-16);
+  block-size: var(--juno-space-16);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  background: transparent;
+  color: var(--juno-label);
+  cursor: pointer;
+  transition: transform var(--juno-motion-duration-quick) var(--juno-motion-ease-standard);
+}
+
+.juno-tree__caret::before {
+  content: '';
+  inline-size: 0;
+  block-size: 0;
+  border-block: calc(var(--juno-space-4) + 1px) solid transparent;
+  border-inline-start: calc(var(--juno-space-4) + 2px) solid currentcolor;
+}
+
+.juno-tree__item[aria-expanded='true'] > .juno-tree__row > .juno-tree__caret {
+  transform: rotate(90deg);
+}
+
+/* A leaf keeps the caret's box so labels line up down the column, but paints
+   nothing — an empty gap would let sibling labels wander. */
+.juno-tree__item:not([aria-expanded]) > .juno-tree__row > .juno-tree__caret {
+  visibility: hidden;
+  cursor: default;
+}
+
+.juno-tree__icon {
+  flex-shrink: 0;
+  color: var(--juno-label);
+}
+
+.juno-tree__label {
+  min-inline-size: 0;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+
+/* Count badge on a group row. Pushed to the trailing edge with the rest of
+   the trailing furniture. */
+.juno-tree__count {
+  margin-inline-start: auto;
+  flex-shrink: 0;
+  font-size: var(--juno-font-size-11);
+  font-variant-numeric: tabular-nums;
+  color: var(--juno-muted);
+}
+
+/* The same trailing-control slot .juno-list__row has: a switch, a menu
+   trigger, a value. Follows the count when both are present. */
+.juno-tree__trail {
+  margin-inline-start: auto;
+  flex-shrink: 0;
+  display: inline-flex;
+  align-items: center;
+  gap: var(--juno-space-8);
+}
+
+.juno-tree__count + .juno-tree__trail {
+  margin-inline-start: 0;
+}
+
+/* ── reorder handle ────────────────────────────────────────────────────
+   The AFFORDANCE and its hit area; the reorder logic is the app's, which is
+   junoui's usual line. It is a real button and always visible on touch: a
+   long-press-drag is the obvious gesture and the wrong one, because a tree
+   sitting on or beside a pan/zoom surface has to let the pan win. An
+   explicit handle is the only unambiguous target — see the doc.
+   `touch-action: none` on the handle ALONE, so dragging it never scrolls
+   while the rest of the row still pans normally. */
+.juno-tree__handle {
+  flex-shrink: 0;
+  inline-size: var(--juno-space-16);
+  block-size: var(--juno-space-16);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  background: transparent;
+  color: var(--juno-muted);
+  cursor: grab;
+  touch-action: none;
+}
+
+.juno-tree__handle:active {
+  cursor: grabbing;
+}
+
+.juno-tree__handle::before {
+  content: '';
+  inline-size: var(--juno-space-10);
+  block-size: var(--juno-border-width-1);
+  box-shadow:
+    0 calc(-1 * var(--juno-space-4)) 0 currentcolor,
+    0 var(--juno-space-4) 0 currentcolor;
+  background: currentcolor;
+}
+
+/* The row being dragged, while the app moves it. */
+.juno-tree__item[data-juno-dragging] > .juno-tree__row {
+  opacity: var(--juno-opacity-muted);
+}
+
+/* Drop target edge. A line rather than a filled row: the drop lands BETWEEN
+   rows, and a filled highlight says "into this one", which is a different
+   operation in a tree and the one users complain about. */
+.juno-tree__item[data-juno-drop='before'] > .juno-tree__row {
+  box-shadow: inset 0 var(--juno-border-width-2) 0 var(--juno-active);
+}
+
+.juno-tree__item[data-juno-drop='after'] > .juno-tree__row {
+  box-shadow: inset 0 calc(-1 * var(--juno-border-width-2)) 0 var(--juno-active);
+}
+
+.juno-tree__item[data-juno-drop='into'] > .juno-tree__row {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: calc(-1 * var(--juno-border-width-2));
+}
+
+/* ── touch ─────────────────────────────────────────────────────────────
+   The caret and the handle paint small so a dense tree stays dense, but a
+   16px target is not tappable. Grow the HIT AREA only, with a transparent
+   overlay, exactly as .nx-check does downstream: a 44px painted caret would
+   swallow the row it sits in. The row's own floor comes from
+   --juno-size-tap-min, which base.css promotes on a coarse pointer. */
+@media (pointer: coarse) {
+  .juno-tree__caret,
+  .juno-tree__handle {
+    position: relative;
+  }
+
+  .juno-tree__caret::after,
+  .juno-tree__handle::after {
+    content: '';
+    position: absolute;
+
+    /* (44 - 16) / 2 = 14 */
+    inset: calc(-1 * (var(--juno-size-tap-comfortable) - var(--juno-space-16)) / 2);
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  junoui — utilities layer
  *