feat(web): Clean up kmwOSK.css in preparation for eventual restyling,

MattGyverLee commented 9 months ago

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:

Inherited CSS variables supported from 2016 to later (https://caniuse.com/css-variables), including Chrome 57, to make the themes consistent and make sense. I was able to remove the duplicate selectors I needed to distinguish iOS dark, iOS light and Android.
:-webkit-any() to combine key selectors where most of the selector was repeated.
rgba() style transparency for fades, because the #00000055 syntax is too recent (CSS4).

Assumptions:

My keyboard’s glyphs were only fully supported in base fonts in Android 6.0 (Marshmallow), so I’m less interested in supporting Android 5. Keyman may still need to support Android 5, but I wonder how many active A5 devices they have.
Keyman 16 requires Keyman 16 for Android requires at least Chrome 57 (from 2019), and Keyman iOS requires OS 12.2, which came out in 2019. This means that we should be able to use CSS that was accepted/available by 2019, so pretty much CSS3. Chrome’s current versions don’t seem to support below devices Android 7, so Keyman may only support back to 7.0. The CSS menus on the KM16 Developer Server don’t seem to work in Android 5-7’s stock browsers.
If I’m right, some older devices, including Android 7, don’t seem to support gradients and transparency in keyboards (even though the browser should), but I could be mistaken. This means that simplified CSS fallback (solid colors) is still necessary. When did this support start?
PopUps and KeyTips will soon be available as children of the keyboard once this feature (9864 (https://github.com/keymanapp/keyman/issues/9864)) is released and reaches stable, and this will allow their CSS to be well constrained by the .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:

.kmw-keyboard-sil\_cameroon\_qwerty .kmw-key:\-webkit-any(
    \[id\*='T\_0300'\],
    \[id\*='T\_0301'\],
    \[id\*='T\_0302'\],
    \[id\*='T\_0303'\],
    \[id\*='T\_0304'\],
    \[id\*='T\_030C'\],
    ...
    \[id\*='T\_1DC7'\]
)

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:

What is the earliest version of Android that you are currently testing Keyman under? Are you still testing 5.0?
The biggest question is, can we use CSS variables in kmwosk.css?
iOS supports dark and light modes for keyboards, is this possible in Android yet?
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?

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

[X] Keyman for Android
[X] Keyman for iPhone and iPad
[ ] Keyman for Linux
[ ] Keyman for macOS
[ ] Keyman for Windows
[ ] Keyman Developer
[x] KeymanWeb
[ ] Other - give details at bottom of form

mcdurdin commented 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:

https://github.com/keymanapp/keyman/blob/2f45cbabcad6c1c58c9c08fc475d4c5693ac9a03/android/help/about/system-requirements.md#L12

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.

MattGyverLee commented 9 months ago

The important question is which version of Chrome. We still support Chrome 37:

https://github.com/keymanapp/keyman/blob/2f45cbabcad6c1c58c9c08fc475d4c5693ac9a03/android/help/about/system-requirements.md#L12

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:

https://github.com/keymanapp/keyman/blob/3ef4dc7f84c920fa7181fed717bb0529f1e708b5/android/KMAPro/kMAPro/src/main/res/values/strings.xml#L36

Has the Chrome 37 ship already sailed in favor of 57? Or it that a warning rather than a requirement?

MattGyverLee commented 9 months ago

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?

https://github.com/keymanapp/keyman/blob/3ef4dc7f84c920fa7181fed717bb0529f1e708b5/android/KMEA/app/src/test/java/com/keyman/engine/util/WebViewUtilsTest.java

mcdurdin commented 9 months ago

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.

mcdurdin commented 9 months ago

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.

MattGyverLee commented 9 months ago

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?

MattGyverLee commented 9 months ago

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.

mcdurdin commented 9 months ago

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.

mcdurdin commented 9 months ago

We could probably go Android 9+ for Keyman 18 but we haven't done our analysis yet.

jahorton commented 9 months ago

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.

keymanapp / keyman