Thanks everyone! I'm still waiting on a confirmation for the last remaining issue on the spec PR <https://github.com/w3c/csswg-drafts/pull/7826#discussion_r990725831> but I hope to have that resolved and the changes enabled in trunk in the next day or two.
I'll update this thread when that happens. On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote: > LGTM3. > > -mike > > > On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss <[email protected]> wrote: > >> LGTM2 under the same conditions! >> >> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor <[email protected]> >> wrote: >> >>> 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] >>> >>> 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. >>> >>> 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 >>> >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc5ab134-bc64-4b28-2120-aa6cd672130a%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/CAL5BFfU-mFYXPwMWpv1WDwN3YwDY-ogU-pKkv9t8-Nson1xWWw%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU-mFYXPwMWpv1WDwN3YwDY-ogU-pKkv9t8-Nson1xWWw%40mail.gmail.com?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/8191816f-fc48-46f6-bae5-69a2114b8507n%40chromium.org.
