Open MattGyverLee opened 9 months ago
- What is the earliest version of Android that you are currently testing Keyman under? Are you still testing 5.0?
The important question is which version of Chrome. We still support Chrome 37:
We want to raise the minimum version of Chrome, perhaps by considering bundling of chromium in a future version of Keyman for Android, but there are a lot of unknowns with this.
- The biggest question is, can we use CSS variables in
kmwosk.css
?
Per https://caniuse.com/css-variables, nope, requires Chrome 49+.
- iOS supports dark and light modes for keyboards, is this possible in Android yet?
Per https://developer.android.com/develop/ui/views/layout/webapps/dark-theme, yes, for Android 10+
- I know my CSS design with gradients is probably way too colorful for the base CSS, so would you be interested in me trying to harmonize the colors and structure of the file at some point?
Yes, for sure. We hope to tackle theming in an upcoming release of Keyman, but it won't make it in 18.0 per our current plan.
The important question is which version of Chrome. We still support Chrome 37:
We want to raise the minimum version of Chrome, perhaps by considering bundling of chromium in a future version of Keyman for Android, but there are a lot of unknowns with this.
This is why I was asking how far back you tested Android. Running Keyman in Android 7, I get this message:
Has the Chrome 37 ship already sailed in favor of 57? Or it that a warning rather than a requirement?
Ok, so 36 is unusable, 37 is "degraded" functionality, and 57 is full functionality? I guess that message is a warning. I know that the stock browser will be lower, but what is the newest version of Chrome supported on Android 5.0?
Has the Chrome 37 ship already sailed in favor of 57? Or it that a warning rather than a requirement?
From memory, Keyman 17 will require 57. Chrome 37 will give degraded functionality in 17.
Okay, so my memory was wrong. Chrome 37 is degraded but mostly works. Chrome 57+ for full functionality. So you could just target that and see how you go. It seems that most Android phones can upgrade their Chrome version.
Chrome 37 is degraded but mostly works. Chrome 57+ for full functionality. So you could just target that and see how you go. It seems that most Android phones can upgrade their Chrome version.
Yeah, that's what I was seeing. I can't create an emulator with Play store that far back (minimum is 7.0), so I can't test upgrading Chrome on 5.0. Actually, Chrome states on their Play store page that they have a minimum of 7.0, so any device pre-A7 may no longer be able to update Chrome through the Play Store (or could possibly get an old version, I don't know). I may be working against myself by providing this detail. :)
I'm curious, can you share a screenshot of your active users' Android versions?
Ok, so Chrome 57 reaches all the way back to Android 5 and 4.1 (https://www.apkmirror.com/apk/google-inc/chrome/chrome-57-0-2987-132-release/). That's good news. Google couldn't tell me this, but APK mirror did.
FYI: Chrome 95 (of 2021) was the last version of Chrome that supported Android 5 (https://www.apkmirror.com/apk/google-inc/chrome/chrome-95-0-4638-74-release/), so that's the EXTREME limit for supporting Android 5, but we don't need to go that far.
For reference, the current version of Chrome is 119 as of this post.
I think I have the information I need to continue. I don't want to tie up any more developer time.
Cool cool, yeah, we support Android 5 up -- other limits on Android 4.x. Wasn't aware of the Chrome 95 limit on Android 5, so that's good to know thanks.
We could probably go Android 9+ for Keyman 18 but we haven't done our analysis yet.
Chrome 37 is degraded but mostly works. Chrome 57+ for full functionality. So you could just target that and see how you go. It seems that most Android phones can upgrade their Chrome version.
To be clear, we insert a number of polyfills so that Chrome 37 is viable with "degraded" functionality. The warning is there because, naturally, it's better not to need those polyfills.
KeymanWeb itself does assume Chrome 57+ and is not distributed with those same polyfills (except for the predictive-text engine, but that's not terribly relevant for this issue). We only add them for the main body of KMW within the Android app at this time.
Yeah, that's what I was seeing. I can't create an emulator with Play store that far back (minimum is 7.0), so I can't test upgrading Chrome on 5.0. Actually, Chrome states on their Play store page that they have a minimum of 7.0, so any device pre-A7 may no longer be able to update Chrome through the Play Store (or could possibly get an old version, I don't know). I may be working against myself by providing this detail. :)
FWIW, a few months back I was able to upgrade a test device that (I think) was using Chrome 38 or similar to a much more modern Chrome - v106. (It was previously incompatible with our build-agent site, preventing me from downloading a test artifact.) Said device is locked to Android 6.0.1. It's possible that the potential limitation you're on would have been introduced more recently, but the anecdotal point suggests that upgrades to older devices are still possible.
And, of note... based on the site you've linked, v106 was indeed the last version of Chrome for Android to support Android 6.0. So... that suspicion re: 5.0 being limited to v95 is pretty well-supported.
Describe the solution you'd like
I’ve been cleaning up redundancy in my CSS to make it more obvious what is going on with the light (iOS Light), mid (Android), and Dark (iOS Dark) themes of my Cameroon Keyboards:
https://github.com/silcam/Cameroon-Keyboard/blob/master/src/km/sil_cameroon_qwerty/source/sil_cameroon_qwerty.css
I’m using these CSS featueres:
:-webkit-any()
to combine key selectors where most of the selector was repeated.#00000055
syntax is too recent (CSS4).Assumptions:
.kmw-keyboard...
class, but I need to include a less-constrained version until that point.Notes on my keyboard:
In my personal code, dozens of duplicate rules like
.kmw-keyboard-sil_cameroon_qwerty .kmw-key:[id*='T_0300']
turn into this more-readable array:I would prefer to use
is()
which is recently (2021) approved to replace:-webkit-any()
, but the webkit version is more widely supported across browser versions though deprecated.Questions:
kmwosk.css
?Next Steps:
Now I’m curious about cleaning/simplifying the
kmwosk.css
in preparation for eventual user-selected themes. Developer-level theming would only need to redefine the colors. Eventual user-selected themes should become more easy in the future if you only have to set a few base and accent colors instead of overpowering every rule. Since this is CSS-based, the options for doing so will rely on the earliest devices/browsers/CSS suppport that Keyman reasonably needs to support.If I did this, I would probably rearrange the .css file, which might make "blame" tracking awkward. Would you want something a bit more 3D/textured like mine or something more "material"?
Keyman apps