feat(developer): Display CSS Key ID in Keycap Properties Panel

[dyacob]

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:

.phone.ios .kmw-keyboard-gff_amharic #punctuation-2-K_1\+shift

and

.tablet.ios div.kmw-key.kmw-key-default[id='punctuaion-extra-U_1225']

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 for Android
• [ ] Keyman for iPhone and iPad
• [ ] Keyman for Linux
• [ ] Keyman for macOS
• [ ] Keyman for Windows
• [X] Keyman Developer
• [ ] KeymanWeb
• [ ] Other - give details at bottom of form

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

[mcdurdin]

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.

[MattGyverLee]

@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

[mcdurdin]

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.

[MattGyverLee]

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!