keymanapp
fix(web): better element inputmode management 📴
Refer to https://github.com/keymanapp/keyman/pull/7343#discussion_r985318712.
If a website designer would normally be specifying input mode for elements that KMW will be managing, we should put forth a good-faith effort to remember what the page's original settings were. At some point, we might even go so far as to support 'intent' behavior in KMW... but not this release cycle.
- In this regard, refer to #1221. It's the main example of a pre-existing feature request I've found in-repo.
User Test Results
Test specification and instructions
User tests are not required
Test Artifacts
- Developer
- iOS
- Keyboards
- Web
- Windows
![keymanapp-test-bot[bot] avatar](https://avatars.githubusercontent.com/in/133554?v=4 "Published by a pub.dev verified publisher"){kind=small}
I appreciate this design. You are trying to prevent
inputModefrom being overwritten by other Javascript code, which would stop Keyman from working.
Not just that - long-term perspective, it'll store updates to the field's intended inputmode. Should we ever support any form of "intents" within KeymanWeb, we could also use that stored value to drive intent-based behaviors. The funky caveat is that we'd need a way to let page devs retrieve their prescribed inputmode.
I wonder if setting inputmode = none only on element focus & removing it on element blur would still hide a device's native OSK while allowing the property to be available most of the time to page devs. But that could get complex and/or brittle. Probably better to just provide a get/set keymanInputMode or something if and when the time comes.
Probably better to just provide a
get/setkeymanInputModeor something if and when the time comes.
Yes. We can't develop in a vacuum. Better to give site developers the tools to connect the dots between their frameworks and Keyman input method than to try and 'magically' make it work ... magic will only get us so far, and then it breaks badly!
