-
Notifications
You must be signed in to change notification settings - Fork 19
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VirtualKeyboard API #16
Comments
Seems odd that there's no Mozilla standards-positions issue on this. |
Nothing official on the Standards Position website, but there is this issue that has no response yet: mozilla/standards-positions#531 |
I have concerns about
|
FWIW, the inability to control how the virtual keyboard appears was brought up as a top pain point by Telegram in a technical post on WebKit issues:
|
If scroll-to-center behavior is bad for their app, there's probably a much simpler feature that could meet that specific need - this API seems too complex to be the obvious way to address this problem. |
VK would only appear if the focus is inside an editable element and there is a sticky user activation. This API lets the web author control the show/hide behavior of the VK only when the |
My understanding is that we will only allow web authors to programmatically show the keyboard using the Virtual Keyboard API in scenarios where authors are already capable of programmatically showing the keyboard by focusing an editable element. (At one point, I recall giving feedback during TPAC that |
This API is something that would be very valuable for developers using Ionic. Our use case is ensuring that inputs that scroll on non-body elements are not covered by the keyboard. The default scroll-to-center behavior in Safari is not ideal because it causes other content to be shifted offscreen. We wrote a "scroll assist" utility to prevent the browser from shifting content off screen while ensuring that the input is not covered by the keyboard: https://github.com/ionic-team/ionic-framework/blob/main/core/src/utils/input-shims/hacks/scroll-assist.ts. Below is an example of the default behavior as well as the custom Ionic behavior:
With the default behavior, observe that the header and part of the content are shifted offscreen. With the custom behavior, observe that neither the header nor the content is shifted offscreen. The downside of this custom approach is we need to estimate the height of the keyboard. This can cause inputs to still be hidden by particularly tall keyboards. It can also cause inputs to be scrolled more than they need to be. Being able to know a) the geometry of the keyboard and b) when the geometry of the keyboard changes would significantly improve the user experience of apps built with Ionic. We do not have a big need for programmatically showing/hiding the keyboard at the moment, but I do see how that functionality could be considered confusing by some. edit: We do also make use of the Virtual Viewport API to get a better idea of the keyboard geometry. Our main problem with that is the event fires after the keyboard is fully open. As a result, we have to wait ~500ms before we can scroll the input into view. This gives the impression of a slow/unresponsive application. |
Apart from preventing the scroll-to-center and the layout viewport shrinking behaviours, which is useful in itself as shown by @liamdebeasi example, this API also provides information about the size of the virtual keyboard. It is provided both through the JS API, and through CSS environment variables ( Such information is useful to properly scroll into view in-flow inputs as suggested above, but also for element which are supposed to be fixed right above the VK. This is very common in chat interfaces, where the text input is usually at the bottom of the viewport by default, and moves up with the keyboard as it opens. It is also common for note taking apps, where you often have a toolbar positioned right above the keyboard. Without this information, there is currently no way to produce these kind of interfaces. As pointed out above, it appears that in Chrome's implementation the
|
This api would also be useful for webassembly projects that afaik currently have no supported way to control the virtual keyboard? |
I want to prevent my own keyboard when there is a native keyboard. |
Gentle ping, any progress on this? If there are concerns of |
Request for position on an emerging web specification
Information about the spec
Design reviews and vendor positions
Bugs tracking this feature
Anything else we need to know
Implemented in Chromium: https://web.dev/virtualkeyboard/
The text was updated successfully, but these errors were encountered: