feat(web): Provide a numberpad layer that embedded apps can switch to

[darcywong00]

While reviewing #1218, @mcdurdin writes

I would like to see us providing a numeric keyboard that is just a number pad layout at some point in the future.

This would be a special keyboard layer included in Keyman Engine, so not visible through the keyboard switcher etc, but embedded apps can switch in for number pad scenarios (e.g. entering phone number)

[darcywong00]

From the community site, @bennylin provides a sample "numeric" layer (minus the autocomplete suggestions)

[mcdurdin]

See also https://community.software.sil.org/t/special-layer-names-in-touch-layout/4568.

We should be considering the various intents that are provided by Android, iOS, web.

[jahorton]

https://community.software.sil.org/t/k-enter-issue-on-some-mobile-apps/7616/2

Of particular note, from my search to provide better info to the user about the complexity...

• https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode
• https://developer.android.com/reference/android/text/InputType
• https://developer.apple.com/documentation/uikit/uikeyboardtype

We do at least have inputmode tracking in place in Web now... we just don't use it for much outside of ensuring the system keyboard doesn't display on mobile devices.

[darcywong00]

https://community.software.sil.org/t/k-enter-issue-on-some-mobile-apps/7616/2

That sounds more similar to #7796

[jahorton]

Regarding iOS, the referenced UIKeyboardType is accessible as a property on the textDocumentProxy object: textDocumentProxy.keyboardType. Just realized while investigating something else, as it's a couple of inheritance layers up and thus isn't immediately obvious from the documentation.

There's also https://developer.apple.com/documentation/uikit/uitextinputtraits/1624446-returnkeytype, which is useful if we want to change-out just the return key label for ENTER-related intents.

[ermshiperete]

Unfortunately I doubt that I'll get to this for Keyman 18, so moving this to the next version. @mcdurdin

[mcdurdin]

Unfortunately I doubt that I'll get to this for Keyman 18, so moving this to the next version.

That's a little disappointing because this has been a longstanding feature request (six years now...) We may want to consider bumping something else instead? (I will move this back to 18.0 for triage when you are back from vacation)

[jahorton]

My personal thoughts at the moment:

• Building a number pad layout should be pretty simple; we have a few defined layouts already within common/web/keyboard-processor's defaultLayouts.ts, so we could define a "numberpad" default with little issue.
  • Assumption: we're just wanting a non-configurable numberpad with standard (Arabic, 0-9) numerals and such... rather than one configured to the current keyboard's script.
• The questions in my mind are more about how we'd toggle in and out of the numberpad. It sounds like it wouldn't be a standard keyboard - or at least not one with a language code. That aspect may well need some design work.
• Thinking about it... wouldn't an emoji keyboard/layer have similar issues? Not tied to a language, not part of most keyboards, etc?

[mcdurdin]

Adding as a Monday Design Meeting topic

[mcdurdin]

despite our wish to do this, we have no capacity for 18.0.