@bluepic/embed 0.4.0-next.169 → 0.4.0-next.170
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/bluepic-embed.iife.js +132 -132
- package/dist/bluepic-embed.umd.js +153 -153
- package/dist/main.cjs +88 -88
- package/dist/main.mjs +18684 -18638
- package/dist/style.css +1 -1
- package/dist/util/visualViewport.d.ts +43 -0
- package/package.json +1 -1
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The on-screen keyboard, as iOS actually reports it.
|
|
3
|
+
*
|
|
4
|
+
* iOS Safari does NOT shrink the layout viewport when the keyboard opens:
|
|
5
|
+
* `window.innerHeight`, `100vh` and even `100dvh` stay exactly as they were
|
|
6
|
+
* (`dvh` tracks the URL bar collapsing, not the keyboard). The only thing that
|
|
7
|
+
* reports the covered space is `visualViewport` — so any layout that has to
|
|
8
|
+
* react to the keyboard has to be driven from JS. There is no CSS-only
|
|
9
|
+
* equivalent on iOS.
|
|
10
|
+
*
|
|
11
|
+
* Android Chrome behaves differently by default (it resizes the layout
|
|
12
|
+
* viewport), which this handles for free: the inset simply computes to ~0
|
|
13
|
+
* because `innerHeight` shrank along with the visual viewport.
|
|
14
|
+
*/
|
|
15
|
+
export declare function useVisualViewport(): {
|
|
16
|
+
supported: boolean;
|
|
17
|
+
height: import("vue").Ref<number, number>;
|
|
18
|
+
offsetTop: import("vue").Ref<number, number>;
|
|
19
|
+
keyboardInset: import("vue").Ref<number, number>;
|
|
20
|
+
keyboardOpen: import("vue").Ref<boolean, boolean>;
|
|
21
|
+
};
|
|
22
|
+
/**
|
|
23
|
+
* Scroll the PAGE so `el` sits inside the visible band, once the keyboard has
|
|
24
|
+
* finished animating in.
|
|
25
|
+
*
|
|
26
|
+
* Why not `scrollIntoView`: it scrolls every scrollable ancestor, and on the
|
|
27
|
+
* mobile layout one of those is swiper's track — which positions its slides by
|
|
28
|
+
* transform. Scrolling it leaves swiper's own offset wrong and the panel
|
|
29
|
+
* misaligned. Moving the page and nothing else is the whole job.
|
|
30
|
+
*
|
|
31
|
+
* Why not just `focus()` without `preventScroll`: same reason, plus iOS ignores
|
|
32
|
+
* it for a programmatic focus often enough to be useless — which is why the
|
|
33
|
+
* field only jumped into view once the user typed.
|
|
34
|
+
*
|
|
35
|
+
* The keyboard animates over ~250–400ms and fires several `resize` events on
|
|
36
|
+
* the way; we wait for a quiet moment rather than guessing a delay, with a hard
|
|
37
|
+
* stop for the case where no keyboard is coming at all (a hardware keyboard, a
|
|
38
|
+
* desktop browser, a field that opened no keyboard).
|
|
39
|
+
*/
|
|
40
|
+
export declare function revealAboveKeyboard(el: HTMLElement | undefined, { margin, hardStopMs }?: {
|
|
41
|
+
margin?: number | undefined;
|
|
42
|
+
hardStopMs?: number | undefined;
|
|
43
|
+
}): void;
|