Open dyacob opened 1 year ago
It's a good idea; we are planning to update the CSS for the keyboards in 18.0, when we rework the OSK, so this could fit into that work.
@dyacob I'm moving over to wildcards *
for identifying my keys in CSS and greatly cut down on duplication in my CSS (many keys appear on both the shifted and caps layer). The code below means that I only need to know the target OS (iOS
in this case) and the Key ID (T_0330
) I defined in KMD, not anything else like the current layer. This could be a bit over-powered for some people, but it works for me. adding the keyboard to the selector gives me just enough specificity to prioritize my changes over the defaults.
.ios .kmw-keyboard-sil_cameroon_azerty .kmw-key[id*='T_0330'] { background: #598059; background: linear-gradient(#ffffff, #aed39f); }
I can still use full identifiers with $
and the layer if I want to be precise:
.android .kmw-keyboard-sil_cameroon_qwerty .kmw-key[id$='K_O'],
.android .kmw-keyboard-sil_cameroon_qwerty .kmw-key[id$='rightalt-K_P'] { background: #978833; background: linear-gradient(#7f7f7f, #beab40); }
Caveats: I still don't think we can reliably restyle popup keys across platforms because of some OS limitations there.
Have you noticed you can nest the CSS for dark mode on iOS? https://github.com/keymanapp/keyboards/blob/5dd5f1d0897c717f4df8e5b75fc980f1bf6e6346/release/sil/sil_cameroon_qwerty/source/sil_cameroon_qwerty.css#L63C1
Caveats: I still don't think we can reliably restyle popup keys across platforms because of some OS limitations there.
Keyman 17 uses web for rendering popups on all platforms. That has pros and cons, but one of the big pros is CSS styling.
Keyman 17 uses web for rendering popups on all platforms. That has pros and cons, but one of the big pros is CSS styling.
That's great news!
Is your feature request related to a problem? Please describe.
It is often difficult to determine the CSS ID (with path, I think this might be called the "selector") of a keycap. My standard approach is to start with the web-based tester and use the Chrome "Inspect" feature and drill down the document tree to find the key, then try to determine the path. It may take a few attempts to get it right. This is particularly challenging with the popup keys which may disappear as you try to "Inpsect" their CSS code.
Describe the solution you'd like
Since the key ID is deterministic, and applies the keyboard name, layer name, and key ID, plus some built-in CSS classes, couldn't KMD do the hard work for us? In the keymap properties for a key (regular, longpress or other) could KMD add the selector string in a read-only field? What I am thinking of are the selectors like:
and
These strings can get pretty long and may not fit comfortably into the properties panel. Displaying them in the status bar would be OK also -if we could copy & paste them from there.
Describe alternatives you've considered
No response
Related issues
No response
Keyman apps
Keyman version
No response
Operating system
No response
Device
No response
Target application
No response
Browser
No response
Keyboard name
No response
Keyboard version
No response
Language name
No response
Additional context
No response