@junoput01/junoui 0.6.0 → 0.7.0

package/dist/css/juno.css

@@ -398,9 +398,30 @@
     var(--juno-size-tap-comfortable) + 4 * var(--juno-space-4) + 2 * var(--juno-border-width-1)
   );
   --juno-dock-clearance-scale: 1;
+
+  /* The bar's own offset from the bottom edge — declared ONCE and consumed by
+     both the bar's margin (dock.css) and the clearance below, so the two cannot
+     disagree about where the bar sits.
+
+     That is the whole reason this is a token rather than a literal in each
+     place. junoui's default is additive, per docs/ios-conformance.md: a
+     FLOATING element sits off the edge, so its gap and the inset stack. A
+     consumer whose design wants the bar flush above the home indicator instead
+     writes `max(8px, env(safe-area-inset-bottom, 0px))` here and BOTH the
+     margin and the reservation follow it. Before this token the form was baked
+     into each site separately, so a consumer that changed one silently
+     disagreed with the other — measured at 16px of dead band at inset 0 and
+     24px at inset 34 (20260815-055), and no single --juno-dock-h could
+     reconcile them because one side added the inset and the other maxed it. */
+  --juno-dock-edge-offset: calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
+
+  /* Gap between the bar's top edge and the last row of content. Zero is a
+     legitimate setting: a translucent bar that content is MEANT to scroll under
+     wants overlap, not breathing room. */
+  --juno-dock-clearance-breathing: var(--juno-space-8);
   --juno-dock-clearance: calc(
-    var(--juno-dock-h) * var(--juno-dock-clearance-scale) + var(--juno-space-16) +
-      var(--juno-space-8) + env(safe-area-inset-bottom, 0px)
+    var(--juno-dock-h) * var(--juno-dock-clearance-scale) + var(--juno-dock-edge-offset) +
+      var(--juno-dock-clearance-breathing)
   );
 
   /* The pillbar is the same shape one size down: no bubble, so its height is
@@ -409,8 +430,8 @@
     var(--juno-size-tap-comfortable) + 2 * var(--juno-space-4) + 2 * var(--juno-border-width-1)
   );
   --juno-pillbar-clearance: calc(
-    var(--juno-pillbar-h) * var(--juno-dock-clearance-scale) + var(--juno-space-16) +
-      var(--juno-space-8) + env(safe-area-inset-bottom, 0px)
+    var(--juno-pillbar-h) * var(--juno-dock-clearance-scale) + var(--juno-dock-edge-offset) +
+      var(--juno-dock-clearance-breathing)
   );
 
   /* JS-readable motion contract. CSS-only `prefers-reduced-motion` never reaches
@@ -527,7 +548,7 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
     .juno-dock__item,
     .juno-pillbar__item,
     .juno-tabs__tab,
-    .juno-list__item,
+    .juno-list__row,
     .juno-menu__item
   ) {
     -webkit-tap-highlight-color: transparent;
@@ -552,9 +573,9 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
   .juno-pillbar__item,
   .juno-pillbar__overflow,
   .juno-tabs__tab,
-  .juno-list__item,
+  .juno-list__row,
   .juno-menu__item,
-  .juno-seg__option,
+  .juno-seg__opt,
   .juno-chip,
   .juno-toggle-btn
 ) {
@@ -1401,8 +1422,10 @@ details.juno-accordion__item:only-child {
 .juno-btn--ghost:hover { background: var(--juno-s2); filter: none; }
 
 /* Small — for dense desktop toolbars (40–46px bars) where the default
-   control would not fit. Deliberately under the WCAG tap-min target:
-   keep the default size for touch surfaces. Combines with --ghost + roles. */
+   control would not fit. Combines with --ghost + roles.
+   On a FINE pointer this is 24px: the WCAG 2.2 AA floor (2.5.8) exactly, and
+   no more. On a coarse pointer it promotes to the comfortable target — see
+   below. */
 .juno-btn--sm {
   min-height: var(--juno-space-24);
   font-size: var(--juno-font-size-11);
@@ -1411,6 +1434,44 @@ details.juno-accordion__item:only-child {
   border-radius: var(--juno-radius-3);
 }
 
+/* --sm names a DENSITY, and consumers reach for it as a SEMANTIC. Audited
+   across one app: 40 call sites, nearly all of them `--sm --ghost` meaning
+   "secondary", shipping a 24px target on a phone — and junoui's own showcase
+   does it twice in a navbar action slot. A size modifier should not quietly
+   become a tap-target decision, so on touch it holds the same floor every
+   other control does. Type and padding still shrink: --sm stays a density
+   modifier, it just stops being a touch-target one (20260826-026).
+
+   THE RULE LIVES HERE, not in base.css's (pointer: coarse) block: a media
+   query adds no specificity, so a `.juno-btn--sm` there would lose to this
+   file's own `.juno-btn--sm` later in the bundle. That is not a guess — it is
+   what silently happened to the .juno-input font floor until 20260815-006
+   measured it.
+
+   --dense is the opt-out, and it is deliberately only meaningful ON --sm:
+   a dense touch toolbar is a real thing (a media scrubber, an editor rail),
+   but it is a decision someone has to make by name rather than inherit from a
+   size.
+
+   The two rules below are REDUNDANT ON PURPOSE, and mutation testing is how
+   that became a decision rather than an accident: deleting either one leaves
+   --dense at 24px. The `:not()` excludes a dense button from the promotion, so
+   the pairing below it is dead weight — until the `:not()` names the wrong
+   class, at which point the pairing (also (0,2,0), and later in the file) is
+   the only thing holding the opt-out. Each covers the other's failure, so a
+   single edit to either cannot silently promote a --dense button. Both
+   selectors are (0,2,0) and mutually exclusive in the correct state, so they
+   never race. */
+@media (pointer: coarse) {
+  .juno-btn--sm:not(.juno-btn--dense) {
+    min-height: var(--juno-size-tap-min);
+  }
+
+  .juno-btn--sm.juno-btn--dense {
+    min-height: var(--juno-space-24);
+  }
+}
+
 .juno-btn:disabled {
   background: var(--juno-muted);
   color: var(--juno-label);
@@ -1750,6 +1811,55 @@ button.juno-chip {
      media query. */
   --juno-dock-scale: 1;
 
+  /* ── Horizontal budget contract ──────────────────────────────────────
+     Published so a consumer's capacity planner ("how many items fit, and
+     do they still hold a tap target?") reads junoui's real geometry
+     instead of re-deriving it from the numbers in this file. Two
+     consumers had derived it by hand, twice, in prose — and both had
+     drifted: they subtracted 12px of inline padding where the pill
+     actually spends 8, so their per-item width came out ~0.8px low at
+     every viewport (20260826-027).
+
+     --juno-dock-items      the item budget. junoui does not enforce it —
+                            __item is `flex: 1 1 0`, so the layout divides
+                            by however many items are present — it is the
+                            number the DERIVATIONS below are about, and the
+                            consumer sets it to what it renders.
+     --juno-dock-item-inline  the width one item gets. A prediction of what
+                            the flex layout produces, not an input to it;
+                            asserted against the measured box in the test
+                            suite so it cannot drift from the layout.
+     --juno-dock-fit-inline  the narrowest viewport at which every item
+                            still holds --juno-size-tap-comfortable. Use it
+                            in a media query and DROP an item; that is the
+                            answer junoui can give exactly.
+
+     A SCALE floor (44px / the item's width) is deliberately not published:
+     it is a ratio of two lengths, and CSS cannot divide by a length. A
+     consumer that must scale rather than drop compares
+     --juno-dock-item-inline against --juno-size-tap-comfortable itself.
+
+     The three inline terms are declared ONCE here and consumed by both the
+     variants' own margin/padding/border and the sums below, so the budget
+     cannot disagree with the bar it describes — the same reason
+     --juno-dock-edge-offset exists (20260815-055). The base bar is
+     full-bleed with a top-edge border only, so all three are zero; --pill
+     and --float set them. */
+  --juno-dock-items: 5;
+  --juno-dock-margin-inline: 0px;
+  --juno-dock-pad-inline: 0px;
+  --juno-dock-border-inline: 0px;
+  --juno-dock-chrome-inline: calc(
+    2 * (var(--juno-dock-margin-inline) + var(--juno-dock-pad-inline) + var(--juno-dock-border-inline))
+  );
+  --juno-dock-avail: 100vw;
+  --juno-dock-item-inline: calc(
+    (var(--juno-dock-avail) - var(--juno-dock-chrome-inline)) / var(--juno-dock-items)
+  );
+  --juno-dock-fit-inline: calc(
+    var(--juno-dock-items) * var(--juno-size-tap-comfortable) + var(--juno-dock-chrome-inline)
+  );
+
   position: sticky;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
@@ -1844,16 +1954,21 @@ button.juno-chip {
 .juno-dock--pill {
   --juno-role: var(--juno-active);
 
+  /* the three inline terms the budget contract sums — see .juno-dock */
+  --juno-dock-margin-inline: var(--juno-space-12);
+  --juno-dock-pad-inline: var(--juno-space-4);
+  --juno-dock-border-inline: var(--juno-border-width-1);
+
   position: fixed;
   inset-inline: 0;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
-  margin: 0 var(--juno-space-12) calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
-  padding: var(--juno-space-4);
+  margin: 0 var(--juno-dock-margin-inline) var(--juno-dock-edge-offset);
+  padding: var(--juno-dock-pad-inline);
   background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
   -webkit-backdrop-filter: blur(12px);
   backdrop-filter: blur(12px);
-  border: var(--juno-border-width-1) solid var(--juno-border);
+  border: var(--juno-dock-border-inline) solid var(--juno-border);
   border-radius: 999px;
   box-shadow: var(--juno-shadow-2);
 }
@@ -1947,17 +2062,22 @@ button.juno-chip {
    Out of flow (fixed) so the page scrolls UNDER it — reserve room on the
    scroller with padding-block-end: var(--juno-dock-clearance). */
 .juno-dock--float {
+  /* the three inline terms the budget contract sums — see .juno-dock */
+  --juno-dock-margin-inline: var(--juno-space-12);
+  --juno-dock-pad-inline: var(--juno-space-4);
+  --juno-dock-border-inline: var(--juno-border-width-1);
+
   position: fixed;
   inset-inline: 0;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
-  margin: 0 var(--juno-space-12) calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
-  padding: var(--juno-space-4);
+  margin: 0 var(--juno-dock-margin-inline) var(--juno-dock-edge-offset);
+  padding: var(--juno-dock-pad-inline);
   overflow: hidden;
   background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
   -webkit-backdrop-filter: blur(12px);
   backdrop-filter: blur(12px);
-  border: var(--juno-border-width-1) solid var(--juno-border);
+  border: var(--juno-dock-border-inline) solid var(--juno-border);
   border-radius: 999px;
   box-shadow: var(--juno-shadow-2);
 }
@@ -2335,17 +2455,44 @@ button.juno-chip {
  *  gap, the folded slot still occupies one gap — name it in
  *  --juno-fold-gap and the fold swallows it with a negative margin.
  *
+ *  COMPOSITION. The canonical use puts .juno-fold on an element that is
+ *  already a component — a .juno-pillbar__item, a .juno-btn, a .juno-chip
+ *  — because that is where the capsule chrome (tap floor, padding, hover,
+ *  focus ring, aria-pressed) lives. Two things follow, and both are
+ *  load-bearing rather than defensive:
+ *
+ *  1. The fold's own declarations are stated at ATTRIBUTE specificity
+ *     (0,2,0), on both branches of data-juno-in, i.e. always. A component
+ *     class is (0,1,0), and `transition` is a SHORTHAND: a later rule does
+ *     not add to the list, it replaces it. Measured in Chromium against the
+ *     built bundle, before this was raised: on a
+ *     .juno-fold.juno-pillbar__item, transition-property resolved to
+ *     `color, background-color` — pillbar.css sorts after this file, so the
+ *     fold had no transition at all and jumped shut instead of folding.
+ *     inline-size and overflow would lose the same way to a component that
+ *     sets either.
+ *
+ *  2. Owning `transition` means owning ALL of it, so the capsule chrome
+ *     properties are in the fold's list too, at the quick duration the
+ *     components themselves use. Dropping them would trade a broken fold
+ *     for a broken hover.
+ *
+ *  Which floors the fold RELEASES when folded — see the folded rule below:
+ *  min-inline-size, padding-inline, border-inline-width. Those are exactly
+ *  the three inputs that can hold a border-box inline size above zero.
+ *
  *  Canonical use: a transient action in a toolbar/pill row (a
  *  scroll-to-top arrow, a contextual button) whose arrival should slide
  *  the row open rather than jump it.
  *  Usage:
  *    <div style="display:flex; gap:4px">                  (any row)
- *      <button class="juno-fold" data-juno-in aria-label="Scroll to top">…</button>
+ *      <button class="juno-fold juno-pillbar__item" data-juno-in aria-label="Scroll to top">…</button>
  *      …other members…
  *    </div>
  *  prefers-reduced-motion needs nothing component-local — the base
  *  layer zeroes every transition duration. */
-.juno-fold {
+.juno-fold[data-juno-in],
+.juno-fold:not([data-juno-in]) {
   --juno-fold-size: var(--juno-size-tap-comfortable);
   --juno-fold-gap: 0px;
 
@@ -2354,13 +2501,32 @@ button.juno-chip {
   overflow: hidden;
   transition:
     inline-size var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    min-inline-size var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    padding var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    border-width var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
     margin var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
     opacity var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
-    visibility var(--juno-motion-duration-base) var(--juno-motion-ease-standard);
+    visibility var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    color var(--juno-motion-duration-quick) var(--juno-motion-ease-standard),
+    background-color var(--juno-motion-duration-quick) var(--juno-motion-ease-standard);
 }
 
+/* Folded away. A min-* floor clamps the USED value whichever rule won the
+   cascade, and a border-box inline size can never resolve below its own
+   padding plus border — so a composed capsule holds the slot open however
+   hard the fold pushes. Measured against the built bundle, composed with
+   .juno-pillbar__item at a 390px viewport: 44px with both floors in place
+   (the tap target), 20px with min-inline-size released (the padding alone),
+   0px with all of them released.
+   min-inline-size is in the transition list above for the OPENING half:
+   released to 0 it would otherwise snap back to the capsule's tap floor the
+   instant data-juno-in returns, and the used width — max(inline-size,
+   min-inline-size) — would jump to full width with nothing to animate. */
 .juno-fold:not([data-juno-in]) {
   inline-size: 0;
+  min-inline-size: 0;
+  padding-inline: 0;
+  border-inline-width: 0;
   margin-inline-end: calc(-1 * var(--juno-fold-gap));
   opacity: 0;
   visibility: hidden;
@@ -4187,11 +4353,20 @@ button.juno-list__row:disabled {
   opacity: 0;
 }
 
-/* the pill — a span after the radio, or the aria-pressed button itself */
+/* the pill — a span after the radio, or the aria-pressed button itself.
+   The tap floor is on the PAINTED box, not on the label that wraps it: the
+   label is a bare inline-flex and takes its height from this. Segmented is a
+   phone-first control and is routinely the only control on a whole settings
+   section, so it holds --juno-size-tap-min like .juno-btn does — 24px (WCAG
+   2.2 AA, 2.5.8) on a fine pointer, promoted to the 44px comfortable target
+   under (pointer: coarse) by base.css. Without it the pill computed ~25px
+   from its padding alone, which is the AA floor by accident and nothing on
+   touch. See 20260826-025. */
 .juno-seg__opt input + span,
 button.juno-seg__opt {
   display: inline-flex;
   align-items: center;
+  min-block-size: var(--juno-size-tap-min);
   gap: var(--juno-gap-control);
   font-family: var(--juno-font-family-sans);
   font-size: var(--juno-font-size-11);
@@ -4239,7 +4414,11 @@ button.juno-seg__opt:disabled {
   cursor: not-allowed;
 }
 
-/* Small — matches .juno-btn--sm; for dense toolbars */
+/* Small — dense toolbars: less type, tighter padding. UNLIKE .juno-btn--sm it
+   does NOT drop below the tap floor, which the base rule above holds: --sm is a
+   density modifier here, not an opt-out of the touch target. A segmented row is
+   often the only control on a settings section, so a sub-tap variant of it has
+   no safe use on a phone. */
 .juno-seg--sm .juno-seg__opt input + span,
 .juno-seg--sm > button.juno-seg__opt {
   font-size: var(--juno-font-size-10);

package/docs/accessibility.md

@@ -115,6 +115,12 @@ tokens land, and never removes a guarantee without a semver-major note.
   base layer raises `--juno-size-tap-min` to the comfortable 44px, so every
   control sized off the tap minimum grows on touch devices. A cascade override —
   the token values themselves don't change.
+- **One control grows on one axis only.** `.juno-pagination`'s items read the tap
+  minimum for `min-inline-size` but carry a fixed `block-size` of 32px, so on a
+  coarse pointer they are 44 × 32 — above the 24px AA floor, below the 44px
+  enhanced one. Tracked as ticket 20260815-040; the numeric coarse-pointer check
+  in `test/visual/tap-targets.spec.mjs` does not cover pagination yet, which is
+  why it went unnoticed.
 - Hover-revealed affordances get a touch fallback: table row actions stay
   visible under `@media (hover: none)`.
 

package/docs/browser-support.md

@@ -166,6 +166,9 @@ declarations in `@supports` costs bytes and buys nothing.
 
 ## Related
 
+- [ios-pwa.md](./ios-pwa.md) — the five-minute version for a consumer about to
+  integrate: what these floors buy you, what you must ship yourself, and what
+  junoui does not do at all.
 - [ios-conformance.md](./ios-conformance.md) — iOS metrics and behaviour: safe
   areas, tap targets, the viewport-unit decision, and the Home-Screen standalone
   letterbox.

package/docs/components/button.md

@@ -14,6 +14,7 @@
 | `.juno-btn`        | Base. Primary (filled): background = role, text = `s0`. Default role = `active`. |
 | `.juno-btn--ghost` | Transparent, `data` text, `border` outline; hover → `s2`.                        |
 | `.juno-btn--sm`    | Dense-toolbar size: `font.size.11`, `space.4` × `space.10`, `radius.3`.          |
+| `.juno-btn--dense` | On `--sm` only: keeps the 24px height on touch as well. Opt out by name.         |
 | `.juno--<role>`    | Sets the primary fill color.                                                     |
 | `:disabled`        | `muted` fill, `label` text, not-allowed.                                         |
 
@@ -28,5 +29,13 @@
 - Primary action filled with `nominal` (confirm) or `active` (apply).
 - `warning` fill only for genuinely critical/destructive actions.
 - One primary per group; everything else is ghost.
-- `--sm` drops below the WCAG tap-minimum on purpose — it is for dense **desktop**
-  toolbars (40–46px chrome bars). Keep the default size anywhere touch is expected.
+- `--sm` is a **density**, not a semantic. It is for dense desktop toolbars
+  (40–46px chrome bars): 24px on a fine pointer, the WCAG 2.2 AA floor (2.5.8)
+  exactly. On a **coarse pointer it promotes to `size.tap.min`** — type and
+  padding still shrink, but the tap target does not. Reaching for `--sm` to mean
+  "secondary" is the common mistake; `--ghost` is the secondary modifier and
+  stands alone at full size.
+- `.juno-btn--dense` opts a `--sm` button back out of that promotion, for a
+  toolbar that is genuinely dense on touch (a scrubber, an editor rail). It does
+  nothing without `--sm`, on purpose: a dense touch target should be chosen by
+  name, never inherited from a size.

package/docs/components/dock.md

@@ -187,6 +187,40 @@ over scroll-event discretization — anything longer visibly lags the finger.
   plus the pill's padding and border), `--juno-dock-edge-gap` (what the
   floating margins take from `100%` — default `2 × space.12`).
 
+## How many items fit
+
+`.juno-dock__item` is `flex: 1 1 0`, so the bar divides its inner width by
+however many items are present. A consumer deciding **how many to render** — and
+whether they still hold a tap target — reads that budget from junoui rather than
+re-deriving it from the numbers in `dock.css`:
+
+| Custom property             | What it is                                                                                                            |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `--juno-dock-items`         | The item budget. **You set it** to what you render; junoui does not enforce it, it derives from it.                   |
+| `--juno-dock-item-inline`   | The width one item gets. A prediction of what the flex layout produces — asserted against the measured box in CI.     |
+| `--juno-dock-fit-inline`    | The narrowest viewport at which every item still holds `--juno-size-tap-comfortable`. Below it, drop an item.         |
+| `--juno-dock-chrome-inline` | The bar's total inline chrome (margin + padding + border, both sides). `0` on the full-bleed bar, `34px` on the pill. |
+| `--juno-dock-avail`         | The width the budget divides. Defaults to `100vw`; override it when the bar is not viewport-wide.                     |
+
+```css
+/* five destinations need 254px; below that, render four */
+@media (max-width: 253px) {
+  .my-dock__item--secondary {
+    display: none;
+  }
+}
+```
+
+The margin, padding and border terms are declared **once** and consumed by both
+the variant's own box and the sum above, so the budget cannot disagree with the
+bar it describes — the same construction as `--juno-dock-edge-offset`.
+
+**There is deliberately no scale floor.** "What scale keeps a 44px target?" is
+`44px / --juno-dock-item-inline`, a ratio of two lengths, and CSS cannot divide
+by a length. A consumer that must scale rather than drop compares those two
+values itself. Prefer dropping an item: scaling a bar scales its hit areas with
+it, which is the problem the floor was being computed to avoid.
+
 ## Anatomy (any platform)
 
 - Full-width bar on `s1`, hairline seam on the block-start edge; items split the

package/docs/components/fold-slot.md

@@ -10,7 +10,7 @@ coming in, end-of-fade going out). Keep the element mounted; flip
 
 ```html
 <div class="juno-pillbar">
-  <button class="juno-fold" data-juno-in aria-label="Scroll to top">
+  <button class="juno-fold juno-pillbar__item" data-juno-in aria-label="Scroll to top">
     <svg class="juno-icon" aria-hidden="true"><use href="…#juno-i-arrow-up" /></svg>
   </button>
   …other members…
@@ -24,6 +24,31 @@ coming in, end-of-fade going out). Keep the element mounted; flip
 | `--juno-fold-size` | The slot's open width (default `size.tap.comfortable`) — must be definite, transitions cannot run to an intrinsic size.         |
 | `--juno-fold-gap`  | The row's flex/grid gap (default `0px`) — the folded slot swallows one gap with a negative margin so the row closes completely. |
 
+## Composing it with a component class
+
+The canonical use puts `.juno-fold` on an element that already carries a
+component class — `.juno-pillbar__item`, `.juno-btn`, `.juno-chip` — because that
+is where the capsule chrome (tap target, padding, hover, focus ring,
+`aria-pressed`) lives. The fold is built for that, and two things about it are
+worth knowing rather than rediscovering:
+
+**Which floors it releases.** A border-box inline size has exactly three inputs
+that can hold it above zero, and the folded state releases all three:
+`min-inline-size` (a component's tap floor), `padding-inline`, and
+`border-inline-width`. Each is in the fold's transition list too, so the content
+neither snaps sideways as the fold starts nor jumps to full width when the slot
+opens. Composed with `.juno-pillbar__item` and none of them released, the folded
+slot lays out at 44px — the tap target — and the row never closes.
+
+**It takes over the element's `transition`.** `transition` is a shorthand: two
+rules setting it do not merge, the winner replaces the loser's whole list. The
+fold's declarations are stated at attribute specificity so it wins that, and its
+list therefore also carries the chrome properties (`color`, `background-color`)
+the components animate — composing costs the capsule nothing. A component of your
+own that composes with `.juno-fold` and needs a third property transitioned
+should state it at higher specificity than `.juno-fold[data-juno-in]` (0,2,0),
+repeating the fold's own entries, or the fold's list wins and yours is dropped.
+
 - The row's own width follows the slot, so the whole row slides open/closed.
 - `prefers-reduced-motion`: handled by the base layer (states still apply,
   transition durations collapse).