I see that Emilio has approved
https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.
LGTM1 to ship w/ the review comments addressed and the PR landing (and
thanks for speccing it!).
On 9/23/22 10:17 PM, David Bokan wrote:
Contact emails
[email protected] <mailto:[email protected]>
Explainer
https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
Specification
The resize behavior of the virtual keyboard is not specified.
The viewport meta tag is not yet fully specified
<https://drafts.csswg.org/css-viewport/#viewport-meta>.
See also https://github.com/w3c/csswg-drafts/issues/7767
<https://github.com/w3c/csswg-drafts/issues/7767>.
Summary
This intent:
* Changes the Android virtual keyboard such that it resizes the
visual viewport only, rather than the current behavior of resizing
the initial containing block (ICB) and layout viewport (LVP).
* Ships support for a new meta-viewport key interactive-widgets
which can be used to opt-out of the above change, and instead
retain the old behavior.
Example: <meta name=”viewport”
content=”interactive-widgets=resize-layout”>
*Motivation
*Browsers do not currently agree on how the virtual keyboard should
interact with the viewport:
*
Chrome for Android and Firefox for Android both resize the initial
containing block and layout viewport.
*
Chrome for ChromeOS and Windows; and Safari/iOS both resize the
visual viewport only.
This discrepancy is a source of frustration for authors [1]
<https://stackoverflow.com/questions/52384678/how-to-stop-soft-keyboard-resizing-chrome-browser-window-on-android-mobiles>
[2]
<https://stackoverflow.com/questions/67800763/how-to-avoid-the-android-keyboard-is-closed-automatically-after-i-click-on-an-in>
[3]
<https://medium.com/@sruthisreemenon/avoid-ui-distortions-during-keyboard-display-for-a-mobile-friendly-webpage-86eb99590a13>
[4] <https://bugs.chromium.org/p/chromium/issues/detail?id=404315>.
While both approaches have valid use-cases, we believe that resizing
the visual viewport is the best default, as it avoids any layout-jank
from opening the keyboard, and in general interferes with the page as
little as possible.
Other vendors also have long-standing issues in this area:
https://bugzilla.mozilla.org/show_bug.cgi?id=1007286
<https://bugzilla.mozilla.org/show_bug.cgi?id=1007286>
This intent improves interop for mobile viewports, a priority
investigation area for Interop 2022 <https://wpt.fyi/interop-2022>.
Mobile viewports (especially the meta tag) are unfortunately not well
specified, and we plan to work on resolving CSSWG issue 7767
<https://github.com/w3c/csswg-drafts/issues/7767> in parallel with
this intent. In the meantime we plan to add this feature to the Compat
spec <https://compat.spec.whatwg.org/>.
Blink component
Blink>Scroll
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll>
TAG review
N/A
TAG review status
Not applicable
Risks
Interoperability and Compatibility
The main risk with this change is web apps which critically depend on
the current LVP-resize behavior, e.g. a chat app with a message box
fixed above the keyboard.
Those use-cases would no longer be possible with the default behavior,
and it was exactly this concern that stopped the previous attempt to
ship this behavior
<https://groups.google.com/a/chromium.org/g/blink-dev/c/Tr43oT4DQoY/m/XRxLWmrrEQAJ>
at LGTM2.
What makes this intent different:
*
The VirtualKeyboard API
<https://developer.chrome.com/docs/web-platform/virtual-keyboard/>
now exists, which exposes the geometry of the keyboard as
CSS-reachable environment variables allowing app full control over
keyboard behavior.
*
For an easier fix, a new <meta> opt-out has been added which can
be used to maintain the current LVP-resize behavior. This is a
trivial fix for any affected web app.
As there is no good way to detect the problematic cases with a
use-counter / HTTP Archive query, we must instead rely on developer
outreach to inform this change. That outreach will reference this
intent, and therefore the results of that will be provided in a
follow-up e-mail.
We expect this change to be a significant win for interop.
*Signals:*
Gecko: No response yet[standards position
<https://github.com/mozilla/standards-positions/issues/693>] (Some
non-official positive signals from Mozilla engineers from discussions
at TPAC and in 7767
<https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-1251680898>
that Firefox could make this change)
WebKit: No response yet [standards position
<https://github.com/WebKit/standards-positions/issues/65>]. The change
to Chromium’s default behavior would now align with WebKit behavior..
Web developers: See “author frustration” links earlier in this e-mail.
Other signals: N/A
WebView application risks
There is no intended behavior change for Android WebView. The Android
app is responsible for sizing the WebView and can implement either
mode via windowSoftInputMode
<https://developer.android.com/guide/topics/manifest/activity-element#wsoft>.
Debuggability
N/A - There's no DevTools functionality directly related to the
virtual keyboard.
Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?
This change affects only Android, bringing it in alignment with
Chrome's virtual keyboard behavior on ChromeOS and Windows.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No. It is currently impossible to test the virtual keyboard as a WPT.
Flag name
OSKResizesVisualViewport
Requires code in //chrome?
Yes - Interaction between web contents container and on-screen
keyboard is implemented in the //chrome layer.
Tracking bug
1353728 <https://bugs.chromium.org/p/chromium/issues/detail?id=1353728>
404315 <http://crbug.com/404315>
Estimated milestones
M108
Note: This change does carry relatively significant compat risk which
is difficult to measure. As such, we’re planning a careful approach.
The feature will have a chrome://flag and enterprise policy to allow
opting-out. We plan to widely share this change via DevRel channels
and closely monitor feedback and bug reports prior to hitting stable
to gauge if a rollback is needed.
Anticipated spec changes
*
The keyboard behavior is not governed by any spec.
*
The “viewport” <meta> is also not governed by any spec at the time
of writing, although there is a recent ambition to change that
<https://github.com/w3c/csswg-drafts/issues/7590>.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6145225857171456
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc5ab134-bc64-4b28-2120-aa6cd672130a%40chromium.org.
