@jsenv/navi 0.29.420 → 0.29.421

package/docs/popup_open.md

@@ -894,14 +894,24 @@ off it (the default of a picker told no value), fields a surrounding form
 submits, a size measured from outside. `"idle"` is `"always"` minus the cost on
 the render that draws the page.
 
-Whatever the value but `"while-opened"`, intent on the anchor — a pointer
-entering it, focus landing in it — builds the content ahead of the click,
-`onOpen` or not. A `"while-opened"` popup is warmed only by a press on what
-opens it (a `--navi-open` button, a picker's trigger when a press opens it, an
-expandable's UI part), throws that content away when the press ends without
-opening it — one content at a time — and is never warmed on a
-`Dialog`/`Popover` with an `onOpen`: the one value where the content is always
-built after `onOpen`.
+Whatever the value but `"while-opened"`, intent on what opens the popup builds
+the content ahead of the click, `onOpen` or not: a pointer over its anchor, or
+focus landing in it. The anchor only says where the popup is placed, so what
+counts is the control that intent is aimed at: the anchor itself when it is a
+control, or the one the popup is written in (a picker's trigger). Any other
+control inside the anchor keeps the intent for itself. A player's own picker,
+inside a card that another picker opens from, warms the player's callout and
+never the card's sheet; tiles anchored on the whole bar they sit in warm only
+the menu of the tile under the pointer. A pointer on a trigger that a press does
+not open — a picker with `openOn={[]}`, or one opened by a hold — warms nothing:
+the card it draws is pressed all day for what it holds. Focus on it still warms,
+since the keyboard opens it.
+
+A `"while-opened"` popup is warmed only by a press on what opens it (a
+`--navi-open` button, a picker's trigger when a press opens it, an expandable's
+UI part), throws that content away when the press ends without opening it — one
+content at a time — and is never warmed on a `Dialog`/`Popover` with an
+`onOpen`: the one value where the content is always built after `onOpen`.
 
 `"while-opened"` is for content whose fresh state is its initial state. An
 untouched field does not need it to show a new `defaultValue`: it follows one

package/docs/scroll.md

@@ -136,7 +136,7 @@ makes that possible is `searchText` on the `List` — without it the list sees n
 children and nothing else.
 
 - **While the search is on**, the list scrolls back to its first row every time
-  the best matches change (the top `renderBudget` rows, by id and
+  the best matches change (as many top rows as the window draws, by id and
   `matchInfo.matchScore`), so a letter that promotes nobody new leaves the list
   where the user put it.
 - **When the search is emptied**, the list returns to the offset it was at when
@@ -286,13 +286,24 @@ sheet, a handful of tabs. A collection whose size the caller does not decide
 </List>
 ```
 
-The run draws only the rows inside the **render window** — `renderBudget` of
-them, 100 by default — and holds the room of the others with fillers, so the
-scrollbar says how long the collection is and the DOM says how many rows fit a
-screen and some. The window slides as the user scrolls, ahead of the direction
-the user goes, so the budget has to exceed what the scroller shows at once,
-with room for that lookahead: the list warns below 30, and when a budget leaves
-fewer than two rows beyond the screen.
+The run draws only the items inside the **render window** — `renderBudget`,
+`"100item"` by default — and holds the room of the others with fillers, so the
+scrollbar says how long the collection is and the DOM says how many items fit a
+screen and some. The window slides as the user scrolls, three quarters of what
+the screen leaves of it ahead of the direction the user goes, so the budget has
+to exceed what the scroller shows at once, with room for that lookahead: the
+list warns when it leaves less than two items beyond the screen.
+
+The budget is a count of items or a size: `"300px"`, or `"150%"` of the
+viewport of the box that scrolls the list. A size is for items that do not
+weigh the same: a list mixing one-line items and full cards (a thread of past
+games and games to come) holds ten times more of the first on a screen than of
+the second. `"100item"` covers four screens of the one-line items and thirty of
+the cards, and nobody scrolls to the thirtieth; a count right for the cards
+leaves blank screens when a fling crosses the one-line items. With a size, the
+window weighs the items it draws where they stand, and an item it has not drawn
+yet like the drawn items next to it — items of one kind come together — then
+weighs it again once it is drawn.
 
 A run whose rows all fit the window is just rows: nothing is virtualized, and
 it costs what the same rows would as children. There is no reason to hold back
@@ -304,12 +315,15 @@ A popup's content is built in the click that opens it (see
 [popup_open.md](./popup_open.md)), and a page coming back in a route transition
 is built in the transition's update callback: rows below the fold cost the same
 there as rows on screen, and delay the movement. `renderBudget` takes
-`{ initial, after }` for exactly this: `initial` rows in the commit the browser
-paints first — what a phone screen shows, plus a few — counted from the row the
-list opens on, and `after` from the paint on. A position handed back with its
-`visibleCount` sizes that first window itself, whatever `initial` guessed. The
-runs ask their source for `after` rows from the start, so the smaller first
-window costs no second request.
+`{ initial, after }` for exactly this: `initial` for the picture the browser
+paints first, counted from the item the list opens on, and `after` from the
+paint on. `initial: "100%"` is the screen and nothing more, whatever the items
+weigh: a few are drawn to be measured, and the window is sized on them before
+the browser paints — a count (`initial: 6`) is a guess that holds for one kind
+of item only. A position handed back with its `visibleCount` sizes that first
+window itself, whatever `initial` says. The runs ask their source for a page of
+items (`<List.Items pageSize>`, 100 by default) whatever either says, so the
+smaller first window costs no second request.
 
 The switch waits for the paint itself. Do not rebuild it with a `useEffect`
 that widens a slice: preact runs a component's pending effects early when that

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.420",
+  "version": "0.29.421",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {