Virtual keyboard; interoperable resizes and opt-in

[David Bokan]

Hello API owners,

I'd like to get your advice on how to proceed with a bit of a tricky interop challenge.

We'd like to align Chromium's mobile virtual keyboard resizing model with WebKit (i.e. resize the visual viewport only, don't reflow the page). This is a longstanding interop pain point. It's also currently blocking us from shipping the new viewport units.

However, changing this by default probably isn't web-compatible. We've tried and failed in the past, and expect there will be PWAs and enterprise apps, as well as UA detecting sites, that don't hit Safari's behavior.

One idea is to add an opt-in for authors. Put another way, consider the existing behavior to be a legacy quirk and add a mechanism to turn off the quirk. e.g.

<meta name="interoperable-virtual-keyboard">

Or

<meta name="viewport" content="width=device-width, ..., virtual-keyboard=resize-visual>

I'm wondering if there's a precedent for this kind of vendor-specific mechanism? In this case, we don't expect other vendors to implement (Safari already has this behavior, Firefox could likely change the default - they don't have the same compat constraints as Chromium on mobile).

What would the process here look like for the opt-in mechanism? We'll document in spec-language how this is parsed and behaves but it seems like something that may not need to be merged into a formal standard, would a small WICG spec suffice to ship? Do we need a TAG review? Get formal signals from other vendors? (I'm about to send out an informal RFC to Gecko/WebKit anyhow). Or would this be the same as any other API? Or is this generally a bad idea for other reasons?

Thoughts/advice much appreciated,

Thanks,

David

[Bramus Van Damme]

Correction: the standalone meta tag would be this, instead of the one mentioned:

<meta name="virtual-keyboard" content="resize-visual">

B!

[Chris Harrelson]

(Caveat: I'm recused in terms of voting on any intent for this, because I'm working closely with the team on viewport units.)

My view  is that we could introduce a "vendor specific" meta tag on a temporary basis in this case, in order to opt into a non-interoperable behavior, and that we could document it somewhere but not require it to be specified.

There is no spec that requires resizing the ICB or not when a virtual keyboard opens. (Though I hope we can spec it in the future.) In a situation like this, there is more leeway IMO to allow a "vendor specific" meta tag for the purpose of helping to smooth the way towards better interop.

Any other API owners with opinions?

Chris

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/fbac0ecf-033c-4f9e-910e-9fa788db5cfan%40chromium.org.

[Ian Kilpatrick]

One thing to keep in mind here is that a lot of sites (Flipkart, Hydrogen matrix client as two examples i found after a few minutes of looking) expect the current Android Chrome behaviour. If we change our behaviour by default we'll end up changing these sites going against developer expectations (there are many blog posts about how to "fix" the iOS behaviour).

A lot of sites assume Android Chrome behaviour - then perform UA sniffing to adjust their site when on iOS. An ideal scenario for many web developers would be that iOS change their behaviour to resize the ICB (to match Android Chrome) - however that isn't going to happen.

Changing this behaviour by default - and consequently the behaviour of these sites seems like a mis-step to me (large compat pain) - and instead we should likely add a way to *opt-into* an interoperable behaviour rather than *opt-out*.

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZu5nnQfVnrZFLEMx3M7DdNWwoQB%2BsYxsgVNorL_zDNi2g%40mail.gmail.com.

[Domenic Denicola]

On Thu, Aug 18, 2022 at 1:47 AM Chris Harrelson <chri...@chromium.org> wrote:

(Caveat: I'm recused in terms of voting on any intent for this, because I'm working closely with the team on viewport units.)

My view  is that we could introduce a "vendor specific" meta tag on a temporary basis in this case, in order to opt into a non-interoperable behavior, and that we could document it somewhere but not require it to be specified.

I'm unsure what distinction between documentation and spec you're making here... a precise spec would probably help developers, especially if, per other messages on the thread, this is likely to become a long-term part of the web platform. I liked the original proposal of a small WICG spec. (Although if it's truly vendor-specific and not really an incubation we expect to graduate, then maybe WICG isn't the right venue.)

 

There is no spec that requires resizing the ICB or not when a virtual keyboard opens. (Though I hope we can spec it in the future.) In a situation like this, there is more leeway IMO to allow a "vendor specific" meta tag for the purpose of helping to smooth the way towards better interop.

Any other API owners with opinions?

Chris

On Tue, Aug 16, 2022 at 10:36 AM 'Bramus Van Damme' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Correction: the standalone meta tag would be this, instead of the one mentioned:

<meta name="virtual-keyboard" content="resize-visual">

B!

On Tuesday, August 16, 2022 at 5:30:20 PM UTC+2 David Bokan wrote:

Hello API owners,

I'd like to get your advice on how to proceed with a bit of a tricky interop challenge.

We'd like to align Chromium's mobile virtual keyboard resizing model with WebKit (i.e. resize the visual viewport only, don't reflow the page). This is a longstanding interop pain point. It's also currently blocking us from shipping the new viewport units.

However, changing this by default probably isn't web-compatible. We've tried and failed in the past, and expect there will be PWAs and enterprise apps, as well as UA detecting sites, that don't hit Safari's behavior.

Have you considered an opt-out mechanism, like a deprecation trial? Feel free to refer me to previous discussions.

 

One idea is to add an opt-in for authors. Put another way, consider the existing behavior to be a legacy quirk and add a mechanism to turn off the quirk. e.g.

<meta name="interoperable-virtual-keyboard">

Or

<meta name="viewport" content="width=device-width, ..., virtual-keyboard=resize-visual>

FYI: http-equiv="" is probably more appropriate than name="" here. Some background at https://github.com/w3ctag/design-reviews/issues/702#issuecomment-1143680791 and https://github.com/whatwg/html/issues/2335#issuecomment-1145372863 which we will try to incorporate into the HTML Standard soon-ish to make this more obvious.

 

I'm wondering if there's a precedent for this kind of vendor-specific mechanism? In this case, we don't expect other vendors to implement (Safari already has this behavior, Firefox could likely change the default - they don't have the same compat constraints as Chromium on mobile).

What would the process here look like for the opt-in mechanism? We'll document in spec-language how this is parsed and behaves but it seems like something that may not need to be merged into a formal standard, would a small WICG spec suffice to ship? Do we need a TAG review? Get formal signals from other vendors? (I'm about to send out an informal RFC to Gecko/WebKit anyhow). Or would this be the same as any other API? Or is this generally a bad idea for other reasons?

Thoughts/advice much appreciated,

Thanks,

David

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/fbac0ecf-033c-4f9e-910e-9fa788db5cfan%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZu5nnQfVnrZFLEMx3M7DdNWwoQB%2BsYxsgVNorL_zDNi2g%40mail.gmail.com.

[David Bokan]

On Wed, Aug 17, 2022 at 8:07 PM Domenic Denicola <dom...@chromium.org> wrote:

Have you considered an opt-out mechanism, like a deprecation trial? Feel free to refer me to previous discussions.

We're still debating this but it was floated as a possibility. It does seem that any kind of temporary measure might make more sense as an origin trial. Do deprecation trials have some leeway in terms of duration and usage or are they treated exactly like regular "new API" trials?

 

 

One idea is to add an opt-in for authors. Put another way, consider the existing behavior to be a legacy quirk and add a mechanism to turn off the quirk. e.g.

<meta name="interoperable-virtual-keyboard">

Or

<meta name="viewport" content="width=device-width, ..., virtual-keyboard=resize-visual>

FYI: http-equiv="" is probably more appropriate than name="" here. Some background at https://github.com/w3ctag/design-reviews/issues/702#issuecomment-1143680791 and https://github.com/whatwg/html/issues/2335#issuecomment-1145372863 which we will try to incorporate into the HTML Standard soon-ish to make this more obvious.

Thanks! Will make sure to check in and follow whatever the settled advice is if we go this route.