@junoput01/junoui 0.7.0 → 0.9.0

package/src/css/components/gizmo.css

@@ -0,0 +1,238 @@
+/* ════════════════════════════════════════════════════════════════════
+ *  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. */

package/src/css/components/swatch.css

@@ -0,0 +1,187 @@
+/* ════════════════════════════════════════════════════════════════════
+ *  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);
+}

package/src/css/components/tree.css

@@ -0,0 +1,259 @@
+/* ════════════════════════════════════════════════════════════════════
+ *  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);
+  }
+}