@jsenv/navi 0.29.404 → 0.29.406

package/docs/safe_area.md

@@ -211,12 +211,16 @@ visible.
 
 An overlaying keyboard is one the browser no longer scrolls the focused field
 out from under, so navi does: when the keyboard rises or resizes, and when focus
-moves to another field with the keyboard up, the focused field is scrolled to
-the nearest position clear of it. That scroll relies on both paddings — the
-`scroll-padding-bottom` counts the keyboard, and the room to scroll into comes
-from the marked element's `padding-bottom`, or, on a page that marked nothing,
-from a block navi adds at the end of the document for as long as the keyboard
-is up.
+moves to another field with the keyboard up, a focused field that is not fully
+inside the document's `scroll-padding` box is centered in it. Chrome paints an
+autofill/suggestion strip above the keyboard that neither
+`env(keyboard-inset-height)` nor `geometrychange` counts, so
+`scroll-padding-bottom` adds `--navi-keyboard-strip-allowance` on top of the
+keyboard — which also keeps Chrome's own caret-following, as a textarea grows
+under typing, clear of the strip. The room to scroll into comes from the marked
+element's `padding-bottom`, or, on a page that marked nothing, from a block navi
+adds at the end of the document while the keyboard is up — both count the
+keyboard and the allowance.
 
 `position: fixed` — so every `FixedBar` — is laid out against the **layout**
 viewport. Where the visual viewport is what shrinks, a bottom bar therefore

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.404",
+  "version": "0.29.406",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {
@@ -34,7 +34,7 @@
     "preact": "^11.0.0-rc.2"
   },
   "dependencies": {
-    "@jsenv/dom": "0.17.77",
+    "@jsenv/dom": "0.17.78",
     "@jsenv/humanize": "1.8.6",
     "@jsenv/validity": "0.4.5"
   },