@jsenv/navi 0.29.387 → 0.29.389

package/docs/autofocus.md

@@ -43,7 +43,8 @@ in order, and stops at the first that leads somewhere focusable:
    so a field naming itself wins over the surface around it;
 3. the first focusable element — what one came to do;
 4. the deepest `autoFocus="last-resort"`, the container itself included;
-5. nothing, and the caller decides what that means.
+5. nothing: the focus stays where it was, and [when the opening places
+   nothing](#when-the-opening-places-nothing) says what follows.
 
 Step 1 is why reopening a popup comes back to where the user was, rather than to
 what the content asks for on a fresh open.

package/docs/badge_list.md

@@ -21,9 +21,11 @@ for, and nothing is set up for a case that cannot happen:
 
 ## How badges are counted
 
-A `Badge` inside a `BadgeList` does not render itself: it hands its props to
-the list through `BadgeListContext` and renders nothing. Badges register in
-tree order, so by the time the list gets to its own content it holds them all
+Once the list has something to decide — a `max`, a `fallback`, `maxLines` — a
+`Badge` inside it does not render itself: it hands its props to the list
+through `BadgeListContext` and renders nothing (a plain list leaves its badges
+to render themselves). Badges register in tree order, so by the time the list
+gets to its own content it holds them all
 and knows how many there are before deciding what to show — without walking
 children vnodes, and without rendering a badge it then has to take back.
 

package/docs/control_group.md

@@ -31,9 +31,10 @@ Stacked, one setting per row:
 </Group>
 ```
 
-`row` (a `Box` prop — its children are laid out as rows, so they stack
-vertically) is the only prop that changes the arrangement; everything else is
-read off the members themselves.
+`row` (or `vertical`, the same prop — each member is a row, so they stack
+vertically and meet along horizontal seams) is the only prop that changes the
+arrangement; everything else is read off the members themselves. Say it rather
+than `flex="y"`: the seams follow `row`, not the layout.
 
 Live examples: `src/control/demos/15_group_demo.html`.
 

package/docs/control_object.md

@@ -36,7 +36,7 @@ It is also the brick composite controls are built from:
 with a value of your own — two wheels that are one number of minutes, three
 fields that are one date. A group with them takes and hands back a single
 value, so it can be driven by one `value`/`signal` like any other control. It is
-what `SpinTime` is made of, and the same mechanism `InputDuration`, `SpinGroup`
+what `TimeSpin` is made of, and the same mechanism `InputDuration`, `SpinGroup`
 and `WheelGroup` use for their own members.
 
 ## `<Form>`: the shape, plus a send

package/docs/control_value.md

@@ -115,9 +115,10 @@ is a value being offered to that control. It is not an action, and it is not a
 signal to write by hand:
 
 ```jsx
-<ControlGroup id="duration">
-  <TimeWheel name="duration" signal={durationSignal} />
-</ControlGroup>
+<WheelGroup id="duration" signal={durationSignal}>
+  <Wheel name="hours">…</Wheel>
+  <Wheel name="minutes">…</Wheel>
+</WheelGroup>
 
 <Button
   command="--navi-update"
@@ -217,9 +218,9 @@ They are not competing, they answer two different questions:
 - `defaultValue` is where the control starts, and where a reset goes back to.
 
 ```jsx
-// "how many players" is what my account usually answers, unless this game says
+// "which levels" is what my account usually answers, unless this game says
 // otherwise — no `??` to write, and no first render showing the wrong one
-<List selectable signal={gameLevelsSignal} defaultValue={me.levels}>
+<List selectable multiple signal={gameLevelsSignal} defaultValue={me.levels}>
 ```
 
 An emptied signal (`signal.value = undefined`) puts the control back on its
@@ -371,8 +372,8 @@ ignored** — on a leaf control as on a group (a selectable list, a checkbox
 group) — and navi says so in dev. One owner, whichever half of the binding you
 look at.
 
-Replacing `value` with `signal` also means dropping the `uiAction` that used to
-write the signal by hand — it is exactly what the binding now does. Keep
+Replacing `value` with `signal` also means dropping the `uiAction` that wrote
+the signal by hand — writing it is exactly what the binding does. Keep
 `uiAction` only for what is not "remember the value": logging, a side effect,
 something else moving with it.
 
@@ -418,10 +419,8 @@ Reference: `src/control/picker/preset/spin_time.jsx`,
 ## See also
 
 - [state_binding.md](./state_binding.md) — the same rule beyond controls:
-
   a `SlideContainer`'s area, a popup being open, the position in the app — all
   bound rather than copied back by a callback
-
 - [form_changed.md](./form_changed.md) — what a form makes of each of these:
   which fields it counts as already answered, and when it sends nothing
 - [control_object.md](./control_object.md) — several controls reading as one

package/docs/css_architecture.md

@@ -22,7 +22,7 @@
 Navi components are styled through a combination of CSS custom properties (variables) and scoped CSS rules. The architecture is designed so that:
 
 1. **Navi wins by default** — the rules that paint and lay a component out are not placed inside `@layer`, so they beat any layered global style. The exception is deliberate and always says so in a comment: a rule navi is happy to hand back sits in `@layer navi` next to the defaults — see [The exception](#the-exception-a-rule-navi-offers-back).
-2. **Defaults are easy to override** — default values for CSS variables are declared inside `@layer navi`, which has the lowest possible specificity, making them trivially overridable from outside.
+2. **Defaults are easy to override** — default values for CSS variables are declared inside `@layer navi`, which any unlayered rule on the same element beats whatever its specificity, making them trivially overridable from outside.
 3. **The preferred override surface is component props** — props translate to inline styles or data attributes, not class names.
 
 ---
@@ -131,13 +131,15 @@ element.setAttribute(SWIPE_AXES_ATTRIBUTE, "x");
 
 ### Beware when moving a shared sheet out
 
-Splitting a chunk out of a template changes **cascade order**: the extracted
-sheet is adopted by the install call, which runs before the component's own
-assignment, so it now comes _before_ that sheet instead of after it. That matters only when the two carry
+Splitting a chunk out of a template changes **cascade order**: in the template
+it sits where it was written, while an extracted sheet is adopted by the install
+call, which runs before the component's own assignment — so its rules come
+_before_ the component's sheet. That matters only when the two carry
 the same selector at the same specificity and in the same layer — check for that
 before splitting. In navi, `popup_css.js` and `surface_text_css.js` overlap
 `.navi_dialog` and `.navi_popover` with dialog's and popover's own css, which is
-why they are still concatenated.
+why dialog.jsx and popover.jsx interpolate them, and mark those two templates
+`jsenv-css-opaque`.
 
 ### A sheet on the far side of a split
 
@@ -182,15 +184,15 @@ lower it. That is the strongest reason not to write one.
 @layer navi {
   /* CSS variable defaults — and, when navi says so, a rule it offers back */
   .navi_button {
-    --button-height: 32px;
-    --button-padding-x: 12px;
+    --button-font-size: var(--navi-control-font-size);
+    --button-border-radius: var(--navi-control-border-radius);
   }
 }
 
 /* The rules that paint and lay out — outside any layer */
 .navi_button {
-  height: var(--button-height);
-  padding-inline: var(--button-padding-x);
+  font-size: var(--button-font-size);
+  border-radius: var(--button-border-radius);
 }
 ```
 
@@ -203,7 +205,7 @@ This means an app can override a Navi default from its own unlayered CSS, withou
 ```css
 /* App CSS — no layer needed, automatically wins over @layer navi */
 .navi_button {
-  --button-height: 40px;
+  --button-font-size: 16px;
 }
 ```
 
@@ -257,10 +259,10 @@ Props are the primary way to customize appearance. They translate to inline `sty
 
 ```jsx
 // Size and color via props
-<Button size="l" primary />
+<Button size="l" color="secondary" />
 
 // Custom CSS variable via style prop
-<Button style={{ "--button-height": "48px" }} />
+<Button style={{ "--button-font-size": "18px" }} />
 ```
 
 #### Variants set defaults, never resolved values
@@ -470,8 +472,8 @@ and a paper could no longer say anything.
 A dialog lives in the browser's top layer and is calibrated on the viewport, so
 an app that is a column in a wide window states its own screen once, on `:root`,
 with `--navi-app-max-width` — and never caps popups through
-`--dialog-max-width`, a `--component-*` token the pickers already write
-themselves. The whole of it, placement included, is in
+`--dialog-max-width`, a `--component-*` token every dialog resets on itself and
+a `maxWidth` prop writes inline. The whole of it, placement included, is in
 [safe_area.md](./safe_area.md#an-app-that-is-narrower-than-the-window).
 
 ### 3. Direct rule override (avoid unless necessary)

package/docs/dialog_shape.md

@@ -16,7 +16,8 @@ Where a `Dialog` sits and how big it gets. What happens _inside_ it (scrolling,
 
 ## A dialog is sized by its content, never by a `width`
 
-There is no `width` prop, and that is the whole design: a dialog is a surface
+`Dialog` has no `width` prop of its own (one handed to it is `Box`'s, still
+under the ceiling below), and that is the whole design: a dialog is a surface
 laid over the app, and what it holds is what knows how wide it should be. What
 a caller states are **bounds** — a floor under a dialog too narrow for its
 content, a ceiling over one that would sprawl:
@@ -50,8 +51,9 @@ Two consequences worth knowing before writing CSS of your own:
   (`--navi-app-width`/`--navi-app-height`, which track the visual viewport), so
   the browser reflows the dialog as the keyboard opens. Nothing to wire.
 - "the container" is the **app's own screen** for `layer="top"` — the visual
-  viewport, or the narrower one the app declared with `--navi-app-max-width`
-  (see [`safe_area.md`](./safe_area.md)) — and the positioned ancestor for
+  viewport minus the app's bands, whether `--navi-app-max-width` centers them
+  or the app writes `--navi-app-inset-*` itself (see
+  [`safe_area.md`](./safe_area.md)) — and the positioned ancestor for
   `layer="local"`.
 
 ## One dialog, two shapes
@@ -185,9 +187,11 @@ its container is also what its size ceiling is computed from. Writing them
 separately is how a dialog ends up flush on one side and inset on the other.
 
 It defaults to a share of whatever holds the dialog (`3appw` for `layer="top"`,
-`3cqw` for `layer="local"`) and accepts a spacing token (`"s"`, `"m"`…), a
-number of pixels, or a viewport length — `appw`/`apph` being the app's own
-screen, `vvw`/`vvh` the visual viewport, which shrinks when the keyboard opens.
+`3cqw` for `layer="local"`) and accepts a number of pixels, a viewport length —
+`appw`/`apph` being the app's own screen, `vvw`/`vvh` the visual viewport, which
+shrinks when the keyboard opens — or a container length (`cqw`/`cqh`). A
+spacing token (`"s"`, `"m"`…) cannot be resolved to pixels here: navi warns
+and places the dialog flush.
 Pass `0` for something meant to sit flush (a side panel), and note that docking
 already passes `0` for you.
 
@@ -241,11 +245,12 @@ exposes both sets of bounds under prefixed names, and they mean exactly what
 they mean on `Dialog` itself:
 
 `dialogMinWidth`, `dialogMinHeight`, `dialogMaxWidth`, `dialogMaxHeight`,
-`dialogExpand`, `dialogExpandX`, `dialogExpandY`, `dockedOnSmallTouchScreen`,
-`marginWithContainer` — plus `popoverMaxHeight` and `popupWidthFitContent` for
-the other shape.
+`dialogExpand`, `dialogExpandX`, `dialogExpandY`, `dialogSizeFromAnchor`,
+`dockedOnSmallTouchScreen`, `marginWithContainer` — plus `popoverMaxHeight` and
+`popupWidthFitContent` for the other shape.
 
-`SplitButton` forwards the same set to the picker it wraps. Anything not in
+`SplitButton` forwards the same set (minus `dialogSizeFromAnchor`) to the picker
+it wraps. Anything not in
 that set lands on the split button's own box instead — so a prop that seems to
 do nothing to the menu is worth checking against that list first (see
 `POPUP_PROP_SET` in `src/control/input/split_button.jsx`).

package/docs/drag_interactions.md

@@ -6,6 +6,8 @@ An element picked up and carried, and what letting go means. It is one gesture
 the gate they go through and how a control learns which of them asked are in
 [interactions.md](./interactions.md); who owns a press when the carried thing
 stands in a box that travels is in [drag_to_travel.md](./drag_to_travel.md).
+Whatever the moment, `event.detail.event` is the `pointerdown` the carry began
+with — for the release as well, unlike a swipe's.
 
 - [Carrying something: `move`, `reorder`, `land`, `toss`, `leave`](#carrying-something-move-reorder-land-toss-leave)
   - [While it is being moved: `moving`](#while-it-is-being-moved-moving)
@@ -29,11 +31,12 @@ differs is the release. One detector reads them all, because it is one press.
 `toss` and `leave` each **combine** with `reorder` and with `land`: dropped on
 another item the element changes places, thrown far and fast it is gotten rid of,
 let go of away from every place it leaves. `leave` combines with `move` as well.
-`toss` does **not** combine with `move`, and neither do `reorder` and `land` with
-each other — one release cannot mean two of those. Declared together, the
-copy-carrying one wins and `move` is never answered — the element itself never
-travels, and a release that is not the other outcome means nothing at all (a dev
-warning says so).
+`move` does **not** combine with any of the three that carry a copy (`reorder`,
+`land`, `toss`), and neither do `reorder` and `land` with each other — one
+release cannot mean two of those. Declared together, the copy-carrying one wins
+and `move` is never answered — the element itself never travels, and a release
+that is not the other outcome means nothing at all; of `reorder` and `land`,
+`land` wins. A dev warning says so in each case.
 
 `move` carries the element ITSELF and leaves it where it was put; the others
 carry a copy and put the original back. That is the same difference said in layout
@@ -50,9 +53,10 @@ place taken by the list.
 ```
 
 `data-drag-free` on the element or a container lets it leave; by default a `move`
-stays inside what one can SEE of its container — which requires that container to
-be a scroll container at all (`overflow` anything but `visible`), since there is
-nothing else for "inside" to mean. A `move` whose answer rejects travels back, because a
+stays inside what one can SEE of its scroll container — the nearest ancestor whose
+`overflow` is `auto` or `scroll`, the page's viewport when there is none — so a
+board that only cuts its content (`hidden`, `clip`) does not hold what moves on
+it. A `move` whose answer rejects travels back, because a
 place the application would not accept must not stay on screen as if it had.
 
 **Where the position is kept is the answer's.** An element drawn from state —
@@ -202,8 +206,9 @@ back, not a row deleted — a list declares `toss`, a surface declares `leave`.
 ```
 
 `leave` combines with every other outcome. Beside `land` or `reorder`, "outside" is
-away from every place. Beside `move` — the element itself travels, and nothing is a
-place — it is outside the surface the element stands in: the nearest
+away from every place. Where nothing is a place — beside `move`, which carries the
+element itself, beside `toss`, or alone — it is outside the surface the element
+stands in: the nearest
 `data-droppable` ancestor, or, without one, what can be seen of the scroll
 container (a dev warning says which). Either way it is judged on the element's
 box no longer overlapping it, not on the pointer, which is still well inside the
@@ -220,8 +225,8 @@ frame when a small marker has just left it.
 </Plan>
 ```
 
-Its detail is `toss`'s — `{ id, x, y }`, the distance travelled being what an exit
-is animated with. Picked up and put straight back down stays a cancel: it has to
+Its detail is `toss`'s without the speed — `{ id, x, y }`, the distance travelled
+being what an exit is animated with. Picked up and put straight back down stays a cancel: it has to
 have gone somewhere to be away from anything.
 
 What the thing does while the answer is asked follows what was carried. A copy
@@ -283,8 +288,8 @@ place, swap the two, refuse.
 />
 ```
 
-`toId` is an element and **never null**: a copy over nothing is a release that
-meant nothing, and the interaction does not happen at all.
+`toId` always names an element and is **never null**: a copy over nothing is a
+release that meant nothing, and the interaction does not happen at all.
 
 **Which elements are places: those marked `data-droppable`, and only those.**
 Declaring `land` says an element can be CARRIED, which on a board is a different
@@ -368,11 +373,11 @@ copy where the hand put it, over the thing appearing there.
 #### Naming what travels
 
 **The copy is already named, and it is the copy that does the visible travel.**
-The wrapper carrying it answers to `navi-drag-clone-wrapper`, the copy inside it
-to `navi-drag-clone`, and `syncCloneWithDropTarget` moves that box onto the
-destination inside the callback — so the piece the hand let go of slides to its
-place whether the application names anything or not. What is left to name is the
-OTHER one: the piece that was standing there and has to go the other way.
+It answers to `navi-drag-clone` (the wrapper carrying it paints nothing and takes
+no name), and `syncCloneWithDropTarget` moves it onto the destination inside the
+callback — so the piece the hand let go of slides to its place whether the
+application names anything or not. What is left to name is the OTHER one: the
+piece that was standing there and has to go the other way.
 
 **And the original is hidden for the whole landing**, not only for the drag: it
 wears `navi-drag-clone-source` (`visibility: hidden`) until the promise returned
@@ -487,9 +492,11 @@ vibration above, a state kept elsewhere, a counter.
 
 `grab` **reports, it does not ask**: what it returns is not waited on, and
 preventing its event does not call the gesture off. And it is not an interaction on
-its own — declared without one of the five above there is no gesture for it to be
-the beginning of, and a dev warning says so. Its detail carries `pointerType` and
-the `gestureInfo`.
+its own — declared without one of the five above (or `moving`) there is no
+gesture for it to be the beginning of, and a dev warning says so, unless the
+element declares `pan` or `zoom`, whose moments they then are
+([pan_zoom.md](./pan_zoom.md)). Its detail carries `pointerType` and the
+`gestureInfo`.
 
 A `longpress` needs none of this: it already happens at the moment the hold is
 acquired, not at the release.
@@ -574,7 +581,7 @@ prevented.
 One outcome refusing refuses the whole gesture — the five answer one carry, and
 something that must not be carried has none of them. Like `grab` and `release`,
 `refuse` **reports, it does not ask**, and it is not an interaction on its own.
-Its detail is `{ pointerType }` and nothing more: there is no `gestureInfo`
+Its detail is `{ pointerType }` beside the press (`event`), and no `gestureInfo`
 because there was no gesture, and what feedback wants to know is which hand asked
 — a vibration for a finger, nothing extra for a mouse whose cursor has already
 said it.
@@ -587,11 +594,11 @@ usually gets its own from the list around it, which the copy has left. So the
 clone's look is the page's to declare, through the attributes the gesture puts on
 it:
 
-| Attribute                 | On                                                     |
-| ------------------------- | ------------------------------------------------------ |
-| `navi-drag-clone`         | the copy being carried                                 |
-| `navi-drag-clone-wrapper` | what positions it (already shadowed, in the top layer) |
-| `navi-drag-clone-source`  | the original, still in place (already hidden)          |
+| Attribute                 | On                                                   |
+| ------------------------- | ---------------------------------------------------- |
+| `navi-drag-clone`         | the copy being carried (already shadowed and scaled) |
+| `navi-drag-clone-wrapper` | what positions it, in the top layer                  |
+| `navi-drag-clone-source`  | the original, still in place (already hidden)        |
 
 ```css
 .task[navi-drag-clone] {
@@ -603,19 +610,19 @@ it:
 Reusing the item's own class is the point: the copy is that item, so it is styled
 as that item plus whatever being carried changes.
 
-**Which is also the trap, for anything positioned on a board.** The copy is the
-same element re-parented into a carrier box, so a geometry written in the style
-attribute follows it there — `width: calc(50% - 2 * var(--gap))` then means half
-of the copy instead of half of the board, and the piece is carried at the wrong
-size. Put what a piece LOOKS like in a class and leave only which place it is
-inline (two custom properties will do), then let it fill its carrier:
+**Which is also the trap, for anything positioned on a board.** The copy is a
+deep clone of the element put in a carrier box, so a geometry written in the style
+attribute comes with it. navi takes back where it stands (`position`, `inset`,
+`margin` and `translate` are reset on the copy) but not its size —
+`width: calc(50% - 2 * var(--gap))` then means half of the carrier instead of
+half of the board, and the piece is carried at the wrong size. Put what a piece
+LOOKS like in a class and leave only which place it is inline (two custom
+properties will do), then let it fill its carrier:
 
 ```css
 [navi-drag-clone-wrapper] .piece {
-  position: static;
   width: 100%;
   height: 100%;
-  translate: none;
 }
 ```
 
@@ -654,8 +661,8 @@ from for as long as the question is open — and if the answer refuses, the copy
 back to it.
 
 `data-drag-axis` says which axes the drag walks, and its default is not the same
-for every outcome: `reorder` alone walks the list (`y`, or `x` for a list that runs
-sideways), while a `move` goes wherever it is put, a `land` wherever the board has
+for every outcome: `reorder` alone walks the list (`y`; a list that runs sideways
+says `data-drag-axis="x"`), while a `move` goes wherever it is put, a `land` wherever the board has
 places, a `toss` wherever it was thrown and a `leave` out by whichever edge (`xy`).
 `data-drag-delay`,
 `data-drag-slop`, `data-drag-threshold` tune when the press becomes a grab.
@@ -728,6 +735,9 @@ leaves the paint alone:
 import { createDragGestureController, dragAfterIntent } from "@jsenv/navi";
 
 const onPointerDown = (pointerDownEvent) => {
+  // Read now: the callback below runs once the intent shows, after dispatch,
+  // when `currentTarget` is null.
+  const element = pointerDownEvent.currentTarget;
   dragAfterIntent(pointerDownEvent, () => {
     const controller = createDragGestureController({
       onDrag: (gestureInfo) => {
@@ -741,9 +751,7 @@ const onPointerDown = (pointerDownEvent) => {
         COURT.PUT.run({ angle: angleSignal.peek() });
       },
     });
-    return controller.grabViaPointer(pointerDownEvent, {
-      element: pointerDownEvent.currentTarget,
-    });
+    return controller.grabViaPointer(pointerDownEvent, { element });
   });
 };
 ```

package/docs/drag_to_travel.md

@@ -192,12 +192,13 @@ laptop a horizontal two-finger swipe IS the back-navigation gesture, and a
 region that neither takes it nor lets it go is the worst of the three — the page
 rocks and nothing happens.
 
-Not the same thing as the drag gesture it sits beside
-([drag_gesture.js](../../dom/src/interaction/drag/drag_gesture.js)): that one is
-for **carrying an object** across the page — it lays a backdrop over the
-document, makes everything else `inert`, takes the focus and blocks the scroll
-keys. Here nothing is picked up and the page must keep its focus and its
-scrolling while a screen slides. Same word, other gesture.
+Not the same thing as **carrying an object** across the page, although both read
+the pointer through the same loop
+([drag_gesture.js](../../dom/src/interaction/drag/drag_gesture.js)): a carry has
+it lay a backdrop over the document, make everything else `inert`, take the
+focus and block the scroll keys. Here nothing is picked up and the page must keep
+its focus and its scrolling while a screen slides, so the travel asks it for none
+of that (`documentInteractions: "manual"`). Same loop, other gesture.
 
 ## Who owns a gesture
 
@@ -324,7 +325,9 @@ page moved a little, and it looked wrong":
   rather than the thing that does the work;
 - **the selection** a drag paints across the text it crosses: `user-select:
 none`, but only once the press has become a travel — a press on text IS how
-  one selects it, and nothing has said otherwise yet.
+  one selects it, and nothing has said otherwise yet. What its first pixels
+  selected is collapsed at that same moment: it was the beginning of the
+  travel, not a selection.
 
 Both are written by the gesture itself (`data-drag-travel-gesture` and
 `data-drag-travel-walking` on `:root`), so a page that bounces the rest of the
@@ -333,8 +336,9 @@ the browser for what those two properties do not cover.
 
 ### What is contained, and what still leaks
 
-Containing is only ever read on a **scroll container** — an element that clips,
-in the browser's sense, whether or not it has anything to scroll. Three places
+Containing is only ever read on a **scroll container** — an element whose
+`overflow` is `hidden`, `auto` or `scroll`, whether or not it has anything to
+scroll (`clip` cuts without making one). Three places
 could carry it: the travelling box, everything inside it, or the scrollers
 themselves. Which of the three works is an engine question, and the answer
 splits in two:
@@ -365,12 +369,14 @@ them is that an empty `textarea` is contained too — a browser cannot be asked
 "only if it scrolls" — so on Blink a wheel over one moves nothing rather than
 the list around it.
 
-On Blink this leaves the boxes that **do not clip**, since those are never
-asked. Of navi's own: `SlideContainer` clips (`overflow: hidden`) and a
-`SidePanel` is a `Dialog`, which scrolls (`overflow: auto`) — both are asked. A
-`RouteTravel` box does not clip and must not be made to: a scroll container
-there would become the nearest one for every `position: sticky` inside the pages
-it holds. A row marked swipeable by `interactions` does not clip either.
+On Blink this leaves the boxes that are **not scroll containers**, since those
+are never asked. Of navi's own: a `SidePanel` is a `Dialog`, which scrolls
+(`overflow: auto`), and is asked. A `SlideContainer` cuts with `overflow: clip`,
+which is not a scroll container (`hidden` would be one, and would let the slides
+off stage be scrolled to), so it is not asked. A `RouteTravel` box does not clip
+at all and must not be made a scroll container: one there would become the
+nearest one for every `position: sticky` inside the pages it holds. A row marked
+swipeable by `interactions` is not one either.
 
 Which is why navi contains what it KNOWS scrolls, in `box.jsx`:
 
@@ -386,7 +392,8 @@ does, and it puts the containment exactly where every engine reads it. A list, a
 dialog body, a scrolling panel inside a travelling page are covered on Blink
 again.
 
-What still leaks, and only on Blink, and only under a box that does not clip: a
+What still leaks, and only on Blink, and only under a box that is not a scroll
+container: a
 scroller **nobody declared and no tag names** — a bare
 `<div style="overflow: auto">`, a widget from elsewhere. Its leftovers reach the
 page, which is the old symptom in a much smaller corner. Two ways out, per case:
@@ -447,10 +454,10 @@ The two ends cost differently, and it is worth knowing which one is being felt:
   and there is no gap at all.
 
 What the browser will not turn around with it is everything ELSE the
-transition carries — see "One gesture that bar cannot follow" at the end of
-this file.
+transition carries — see [One gesture that bar cannot
+follow](#one-gesture-that-bar-cannot-follow).
 
-Two things a travel in hand must never lose:
+What a travel in hand must never lose:
 
 - **a travel being undone is not up for grabs.** Its end is already decided;
   held again mid-revert, its animations never finish, the wait for them never
@@ -546,13 +553,13 @@ travel had started finishes without anyone. It is invisible with a mouse, which
 is why it survives a whole session of desktop testing.
 
 So a travel that has become ours refuses the `touchmove` (`preventDefault`), and
-only then — a finger that means to scroll must still scroll. Two details make it
-hold:
+only then — a finger that means to scroll must still scroll. Three details make
+it hold:
 
-- the listener sits on the element the touch LANDED on as well as on the box: a
+- the listener sits on the element the touch LANDED on as well as on the window: a
   touch keeps being dispatched at the node it started on, and a travel may
   replace the DOM under the finger (a page that travels navigates), after which
-  that node no longer passes through the box on its way up;
+  that node no longer passes through the window on its way anywhere;
 - the pointer is captured on the BOX rather than on what the finger landed on,
   for the same reason: what the caller does may take that target away, and a
   capture whose element leaves the document is a capture the browser drops;
@@ -659,7 +666,8 @@ aimed decides what that costs:
     at half of its time a travel has covered ~80% of its distance, and rewound
     at `-1` the visible way home collapses into the steep end of the curve — a
     snap, not a return. The pictures walk home over how far they visibly are
-    from home, at the travel's own pace (`revertWalkTime`);
+    from home, at the travel's own pace (`walkPicturesHome` in
+    `src/transition/view_transition_revert.js`);
   - both of the above run straight into the compositor traps: the distance is
     computed from the clock through the easing curve (the pseudo-elements'
     animated position cannot be read), and the rate is handed over with

package/docs/dynamic_import.md

@@ -126,9 +126,9 @@ what asks, not to the render.**
 
    It starts one render late, and per instance: a component fetched this way
    in three places asks three times (the browser fetches the module once), and
-   coming back to it suspends for the microtask the import takes to answer
-   from the module map. Reach for it when there is genuinely no state to read
-   the request off — not to save declaring one.
+   coming back to it draws its wait again for the microtask the import takes to
+   answer from the module map. Reach for it when there is genuinely no state to
+   read the request off — not to save declaring one.
 
 Delegating instead (the hook without `loading: true`, under a `<Loading>`
 around the frame) follows the rule for data: **the `<Loading>` goes where the
@@ -210,8 +210,10 @@ The page or the component reading its code says it where it stands, as
 above. A failure left to a boundary — a page reading its code without
 `error: true` — reaches it like a failed read does; a boundary that shows only
 what came from the network and rethrows the rest as a bug recognises an import
-by its action — `error.action` is the route action the app declared for the
-code — rather than by the browser's message.
+by its action rather than by the browser's message. `error.action` is the
+instance that ran, not the route action itself (a route action hands out the
+instance for its params), and every instance bound from one action carries its
+`callback`: `error.action.callback === GAME_PAGE_CODE.callback`.
 
 ## Preact's `lazy()` is not this