Normalize key to uppercase on MacOS when Shift is held
#116
Conversation
| @@ -108,7 +108,6 @@ for (const el of document.querySelectorAll('[data-shortcut]')) { | |||
| 6. `"Mod"` is a special modifier that localizes to `Meta` on MacOS/iOS, and `Control` on Windows/Linux. | |||
| 1. `"Mod+"` can appear in any order in a hotkey string. For example: `"Mod+Alt+Shift+KEY"` | |||
| 2. Neither the `Control` or `Meta` modifiers should appear in a hotkey string with `Mod`. | |||
| 3. Due to the inconsistent lowercasing of `event.key` on Mac and iOS when `Meta` is pressed along with `Shift`, it is recommended to avoid hotkey strings containing both `Mod` and `Shift`. | |||
There was a problem hiding this comment.
maybe we should still mention that this might cause inaccessible shortcuts for non-US-QWERTY users?
|
|
||
| // MacOS outputs lowercase characters when `Command+Shift` is held, so we map them back to uppercase if we can | ||
| const shiftNormalizedKey = | ||
| hotkeyString.includes('Shift') && matchApplePlatform.test(platform) |
There was a problem hiding this comment.
a thought: maybe we should only normalize for Mod hotkeys: that way using the raw Meta like Meta+Shift+lowercase would still be an option?
There was a problem hiding this comment.
Although Meta+Shift+lowercase wouldn't work on Linux :(
There was a problem hiding this comment.
That's not a bad idea - I like the opt-in normalization you get there. Meta alone won't actually work on Linux at all I think.
There was a problem hiding this comment.
Ooh, but it doesn't work in this case because we are just converting events to hotkey strings - we don't yet know what the target string is that we will be comparing it to since this is a lower-level util.
…e-uppercase-macos
iansan5653
force-pushed
the
normalize-uppercase-macos
branch
from
3d792c5 to
f2c43dc
Compare
Uses a map of 'lowercase' (non-shifted) symbols to their corresponded uppercase/shifted counterparts to normalize
keyon MacOS to always be uppercase whenShiftis held.This only attempts to address the issue for US/QWERTY layouts as was our approach with
Altsupport, however the approach should work for all US layouts because it still usesevent.keyand notevent.code. We could use the more generaltoUpperCasefor character keys to try and support more languages, but I think it's better to limit this normalization to what we know for sure, and let consumers handle more advanced cases if they need to. This works for all GitHub applications because we only use latin characters for shortcuts.Shiftkey with uppercase letter hotkeys #115