@jsenv/navi 0.29.176 → 0.29.178

package/docs/css_architecture.md

@@ -560,28 +560,25 @@ from the app. Two reasons:
   that knob, so a popup that genuinely needs its own `maxWidth` can still say so
   without any of them escaping the app's screen.
 
-##### Current limitations
+##### Placement follows the same rectangle
 
-`--navi-app-max-width` caps how big a popup may get; it does not move where one
-is placed. Placement is still computed against the real viewport
-(`pickPositionRelativeTo`, in `@jsenv/dom`). That is invisible for anything
+`--navi-app-max-width` moves where a popup is placed, not only how big it may
+get. Placement is computed against the visual viewport narrowed to the app's
+own rectangle: navi hands the centered bands to `@jsenv/dom` once
+(`setPlacementViewportInsets`, wired in `navi_css_vars.js`), and
+`pickPositionRelativeTo` reads them on every placement. Invisible for anything
 centered on its cross axis — `center`, `bottom`, `top`, which is what a dialog
-does nearly always — but shows for anything anchored to an edge: a
-`positionArea` like `bottom-start`, a `SidePanel`. Those sit against the
-window's edge rather than the app column's, so they stay on the real viewport
-for now (`side_panel.jsx` restates `--dialog-maxmax-width` as the full viewport
-on purpose).
-
-`FixedBar` is the exception, and shows the shape of the fix: it is pinned to
-`--navi-app-inset-*` (see `docs/safe_area.md`), which describes where the app's
-rectangle is in the window rather than how wide it may be. Making the rest
-follow means narrowing the container rect placement is computed against, inside
-`pickPositionRelativeTo`, to that same rectangle.
-
-Note that an app can already get all of it, placement included, by rendering
-itself in an iframe of the target width: the viewport then genuinely _is_ the
-app's screen and no token is needed at all. `--navi-app-max-width` is the answer
-for an app that does not want to pay that price.
+does nearly always — but it is what puts anything anchored to an edge (a
+`positionArea` like `bottom-start`, a `SidePanel`) flush against the app
+column's edge rather than the window's. `FixedBar` reads the same description
+through CSS instead: it is pinned to `--navi-app-inset-*` (see
+`docs/safe_area.md`), which says where the app's rectangle is in the window
+rather than how wide it may be.
+
+Note that an app can also get all of it by rendering itself in an iframe of
+the target width: the viewport then genuinely _is_ the app's screen and no
+token is needed at all. `--navi-app-max-width` is the answer for an app that
+does not want to pay that price.
 
 ### 3. Direct rule override (avoid unless necessary)
 

package/docs/drag_to_travel.md

@@ -147,26 +147,25 @@ to get wrong from there:
   which: once it has faded into a recognized tail, growing **twice in a row**
   is a hand (`WHEEL_REGROW_RUN`) — decay jitter bumps up in isolated events and
   never twice consecutively.
-- **the other axis, over a faded stream, is not ours to swallow.** Within a
-  push, cross-axis events are the push's own wobble and are eaten with the
-  rest — a hand is never perfectly straight. But once our axis is momentum
-  only, a hand pushing the other way is a NEW gesture, and on an axis the box
-  does not travel it is not ours at all: it is handed back to whatever scrolls
-  under the pointer, untouched, and it does not renew the claim either. Renewed
-  by what it swallows, the gesture would be kept alive by the very scroll it
-  ignores — every attempt extending the silence it was waiting for. Handed
-  back, though, only when it IS a scroll: at the end of a fade the deltas are a
-  pixel or two on each axis, and read alone such an event says "the other
-  axis" as easily as it says nothing — passed along, those crumbs scroll the
-  slide's own content a few pixels under the travel, a header creeping off the
-  edge of the box. Three things separate a scroll from the crumbs, and all
-  three are asked for: the other axis clearly dominates the event (the same
-  bar a drag uses to give up its press); the event is the size of a hand, or
-  the run is growing event over event — a scroll ramping up from rest, which
-  decay never looks like; and it is a RUN — wobble is isolated, a scroll
-  insists (`WHEEL_CROSS_RUN`, `WHEEL_CROSS_CONFIRM_DELTA`). The run costs a
-  real scroll its first event or two — a few pixels, one notch of a stepped
-  wheel — which is the cheap side of the trade.
+- **cross-axis events are swallowed absolutely, and they renew nothing.** A
+  hand is never perfectly straight, so events leaning the other way are the
+  gesture's own wobble and are eaten with the rest — and there the swallowing
+  has to be total, because no per-event reading tells a scroll's onset from
+  that wobble. It was tried, and every filter leaks: end-of-fade crumbs are a
+  pixel or two landing on either axis (a `(0,1)` event is "clearly the other
+  axis" by any dominance test), a slightly diagonal swipe's tail carries
+  hand-sized deltas on both axes, and one crumb let through scrolls the
+  slide's own content under the travel — a header creeping off the edge of the
+  box, one pixel per leak. Do not re-attempt a "hand it back when it is really
+  a scroll" heuristic; the honest boundary is elsewhere: a swallowed
+  cross-axis event does NOT renew the claim. Silence is the only end a wheel
+  gesture has, and it is silence ON ITS AXIS — renewed by what it eats, the
+  gesture would outlive its own stream, and a hand starting a scroll over the
+  tail would extend, event by event, the very deadness it was waiting out.
+  Left to lapse, the claim dies shortly after the travel axis goes quiet (on a
+  system where touching the surface kills the old momentum, that is moments
+  after the new scroll begins), and the browser answers the rest of the scroll
+  itself.
 
 Taking it is also the only way to stop the browser from answering it: on a
 laptop a horizontal two-finger swipe IS the back-navigation gesture, and a

package/docs/safe_area.md

@@ -151,11 +151,14 @@ _sizes_ must fit what is actually visible.
 and turns the bottom bar's number red when it goes under the keyboard. On a
 phone; a desktop has no keyboard to open.
 
-## Current limitation
-
-Popup **placement** does not follow level 1 yet: `pickPositionRelativeTo` (in
-`@jsenv/dom`) still computes against the real viewport. Invisible for anything
-centered on its cross axis — which is what a dialog does nearly always — but a
-`positionArea` like `bottom-start` or a `SidePanel` sits against the window's
-edge rather than the app column's. See "Current limitations" in
+## Placement follows level 1
+
+Popup **placement** answers to the level-1 rectangle too: `getAppInsets`
+(`src/layout/responsive.js`) is the JS reading of the level-1 bands, and
+`pickPositionRelativeTo` (in `@jsenv/dom`) computes against the visual
+viewport narrowed by them (`setPlacementViewportInsets`, wired in
+`navi_css_vars.js`). Invisible for anything centered on its cross axis —
+which is what a dialog does nearly always — but it is what puts a
+`positionArea` like `bottom-start` or a `SidePanel` against the app column's
+edge rather than the window's. See "Placement follows the same rectangle" in
 `css_architecture.md`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.176",
+  "version": "0.29.178",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {
@@ -29,7 +29,7 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "@jsenv/dom": "0.17.42",
+    "@jsenv/dom": "0.17.44",
     "@jsenv/humanize": "1.7.8",
     "@jsenv/validity": "0.4.3"
   },