Broadening the Scope of the Specification to Support Mobile Devices

[nxtexe]

Summary
What problem would this solve?
The problem this would solve is that on mobile there is no way to programmatically request the use of the soft keyboard which makes it difficult for rendering solutions on the web that do not use html to render UI to get user input.
In the Keyboard Map specification I found:

4. Mobile Device Considerations
   Since this is a keyboard-focused API and mobile devices do not commonly have physical keyboards, this API will not typically be present or supported on mobile devices.

However, mobile devices may choose to support this API if they allow physical keyboards to be connected. In this case, they may return a subset of the Writing System Keys that are appropriate for the platform.

Mobile platforms that require the user to configure their physical keyboard layout (and don’t provide a reasonable default), may support this API by returning a layout map that contains no entries.

Audience
Who has this problem? Everyone? Article authors? Etc.
The audience this problem affects is developers looking to leverage wasm to offer near native web experiences. The web is moving to evolve using wasm for performance in combination with javascript. As it stands right now, UI can be drawn using wasm on a html5 canvas, but when it comes to user input on mobile, some weird workarounds have to be used in order to achieve the end goal of getting user input from the soft keyboard.

Rationale
How do you know that people identified above actually have this problem?
I know the people identified have this problem as I am currently developing an application to render using the html5 canvas, but keyboard input is tricky on mobile, near impossible since I can't get access to the soft keyboard programmatically. There is also no way to even get any information about the keyboard such as the height of the keyboard, layout of the keyboard etc. There is also no way to control how the keyboard is displayed over your application.

Workaround
How are the people identified above currently handling this problem?
I currently use a workaround in which I use hidden html elements to solve the problem. I have a top layer element preferably an <a> tag, that captures touch events and behind the canvas is an <input> tag. I register a touch event listener on the <a> tag and inside the event listener callback function I grab the input tag behind the canvas and call it's .click method which brings the keyboard up. This workaround isn't guaranteed to work, especially on safari (iOS) where it doesn't work at all. I've only gotten it to work on android devices using chrome.

Proposal
Do you have suggestions for solving this problem?
Implementing an expansion of the Keyboard API using Web IDL bindings could solve the issue. I am however aware of the web security issues that this feature poses, but with wasm currently offering the potential to give near native performance, we should find ways to safely provide such a core functionality. One consideration I was thinking of for enhanced security since this proposal does have the ability to change the state of the user's device is to have a similar operation to what mobile applications do and also is becoming more popular on the web is to ask the user for certain permissions.