4 ms·

I'm sure there is a use-case for this, but normally when I look at controversial Chrome features it's immediately obvious why I'd want them (risks aside), or at

I'm sure there is a use-case for this, but normally when I look at controversial Chrome features it's immediately obvious why I'd want them (risks aside), or at least why someone would want them -- but with this feature I'm having a hard time imagining what I'd ever build that would want to use it. Going off of physical locations of keys is pretty bad UX practice for shortcuts as far as I know; we pretty much always want keys to be remappable either in software or at the OS level. Games spring to mind (WASD), but games definitely want remappable keys, and it's not clear to me that this (to use a Chrome term that I kind of like) is encouraging developers to fall into a "pit of success" in regards to gaming and user controls. This has popped up occasionally for me where gamepads are concerned -- it's nice to be able to provide a sensible default when someone plugs in a controller. But in that situation I care more about just having a default layout then I care about knowing the specific key that was pressed. In that scenario what I actually want is a gamepad "type" string that I can just map to a list of defaults I've pre-configured for that specific gamepad type. In fact, the more I think about it, getting a key code is almost the opposite of what I want in that situation since different gamepads have different norms about what locations should do what and are shaped differently, there isn't a universal map. It's explicitly the wrong decision for me to say that the top button on the right hand side of a gamepad will always do one thing, because that's going to breaking norms on different controllers. And it seems like keyboards are kind of the same? I sort of see the value of a keyboard being able to signal a common layout that has different default shortcuts, but I'm having a really hard time thinking beyond that why I would want to as a dev override normal shortcuts. Okay, sure, it would be nice to query that a keyboard is in AZERTY layout and suggest different shortcuts. Beyond that? Enough people have asked for it that it must have a use, but even from a gamedev perspective this seems like a strange API to me. The privacy angle is one thing, but I also just have an instinct that this is probably not a behavior that users want from applications. They probably want Internet applications to respect their shortcuts instead of overriding them. And they probably want games to avoid forcing controls based on physical locations of buttons. ---- From the Github spec: > E.g., If a game supports the standard WASD keys (to move up/left/down/right), then the instructions for the game need to be able to tell the user which keys to press. On a US-English keyboard, they are 'W', 'A', 'S', 'D', but for French (AZERTY) layout the user would be told to use 'Z', 'Q', 'S', 'D'. [...] > Some applications make use of keyboard shortcuts that are based on the position of the key rather than the symbol that is generated. [...] > E.g., a drawing app may have a number of drawing modes arranged from left to right on the screen and may wish to have keyboard shortcuts that correspond to the screen position. I don't know, maybe I'm being unimaginative. But I've dealt with at least the first problem here, and I don't think that keymaps are necessarily the best way to solve it. Also, if we're talking about games we should be coming up with a solution that maps to controllers as well, so I don't really get why we're going down this specific route. And the second two use-cases seem like user accessibility bugs, not features. I guess enough devs want it that Chrome is implementing it, but I feel like there's something I'm missing. As a user, I want a user-controlled (or at least OS-controlled) layer between myself and app shortcuts/keycodes; it's super useful and I customize that layer all the time, even for simple things like rebinding caps-lock. And as a dev I'd rather not have to try and intuit what setup a user has based on physical locations. Heck, maybe someone toggles into a different layout to game and they use IJKL to move around when they're playing web games. Maybe their W key is broken and it's bad for me to try and force them to use that specific physical button. I don't want to have to think about any of that as a dev, just have the OS signal to me what keys they want me to think they pressed. And if they can signal to me a common string for the overall layout that allows me to give them a sensible default, then great, I'm happy to do something like that. But this feature doesn't seem to make any of that easier, it just gives me a granular map for individual keys and then makes it my problem to interpret. :shrug: I don't know, maybe there's some nonsense with native behavior that we're trying to match or something. I customize my keyboard layout a lot, but I've never jumped to DVORAK/AZERTY, maybe there's a lot of weirdness with shortcuts there that native apps expect to just paper over, where they bypass the layout? But I'm not really seeing that online?

zamadatix 5y ago
> But I've dealt with at least the first problem here, and I don't think that keymaps are necessarily the best way to solve it. Curious how you solved the WASD problem not if not by using a keymap in some way? > we should be coming up with a solution that maps to controllers as well The gamepad API already normalizes axes/buttons. > As a user, I want a user-controlled (or at least OS-controlled) layer between myself and app shortcuts/keycodes That'd be great but there is no reason this couldn't be pursued as a separate layer on top of this instead of something that has to block it. I doubt it'd get the same support though as it'd require a lot more "thou shalt do it this way" rather than "you can call this if you need" and such changes are much harder to get support for.
- danShumway 5y ago
  > Curious how you solved the WASD problem not if not by using a keymap in some way? Short answer, I just give the users an option to change their keyboard layout and use arrow keys/mouse as a backup for menu traversal in case they set their bindings weird and get stuck. For apps where that's annoying to prompt, I still provide the option but default to assuming QWERTY layout unless I see some signal (language options) that tells me I should more explicitly ask. Longer answer, I don't have hard stats and this is mostly just based on my intuition, but my feeling is: - QWERTY tends to be a pretty safe default for most US users, DVORAK tends to be either uncommon or the people using it already have custom maps set up, which I don't want to mess with. - Other layouts tend to be associated with other languages, so using `navigator.language` seems to be a decent proxy? At the least, if `navigator.language` says something other than "en-us", at that point I might decide to surface a prompt to pick a keyboard layout. - Users would rather be able to select their controls from a list (ie, have some keybinding "templates" or common schemes that players can toggle on) and then customize them, rather than have to build their control-scheme from scratch. ---- I do think it would be easier to have better defaults if I could look up the base layout from a list of common values and default them to a layout that's likely close to what they want. Something like `navigator.keyboard.getLayout` would be useful to me, similar to `id/mapping` on a gamepad. There are privacy risks there too, but I see the use case at least. But that's not really the same thing as wanting a map of every key, a map of every key is less useful to me than a string that says "DVORAK". It's also important to understand that displaying the key on the screen isn't actually the problem here; I don't really understand what the Github repo is talking about in that sense. Without the new API, the prompt you display on the screen will always be correct 100% of the time: if you tell the user to press the "W" key, they'll press the key they associate with "W". So the problem is not "how do I tell the user which key to press", it's "which key should the user press?" And in that situation all you're really looking for is the ability to set sensible defaults; I can't think of an example where I've wanted to be prescriptive about "the user must use their left hand to navigate, and it must be in the location of WASD". So I don't really know what I'd even use a full keymap for, the most I want is a signal for which pre-defined default keymap I should load up. I guess I can use `getLayoutMap` to do that, but it's clumsy and inflexible and requires extra coding: it's kind of an inferior solution to just giving me a layout string that I match against a table. Matching against a table based on ID/layout is also what I already do for controller defaults, so it's annoying to me to have a separate system somewhere else. ---- I mentioned "pits of success" above. There are a few traps and good practices when working with keybindings (opinion me). Some bad outcomes: - Not having rebindable keys or alternate layouts that the user can set. - Not respecting user-rebound keys (my caps lock is escape, I want that button to register as escape in everyone's web app). - Showing inaccurate information onscreen, telling the user to press "W" when you mean something else. Note that this is impossible to do without `getLayoutMap`, and very easy to do with `getLayoutMap`. Some positive results: - Having better default keybindings, as long as they can still be changed As far as I can tell, giving devs the option to ignore user keymaps and to use physical key positions for bindings makes it easier for them to fall into the first 3 traps, and only marginally helps with the second positive result. ---- Anyway, second TLDR, have some common layouts in your key rebinding options that people can quick-select (you probably should have this for WASD/arrow-key toggling anyway, not everyone on QWERTY layouts likes WASD). If you're worried about defaults, use `navigator.language` as a signal for whether you need to be more proactive about asking for the keyboard layout up-front. I also don't really understand what the Github repo is talking about when it says that displaying messages is hard, because as far as I can tell messages about what key to press are the only part of this that are currently impossible to break, and I'm a little annoyed Chrome has now made it possible to break them. Again, maybe there's something I'm missing, I assume devs have some reason for asking for this. I just can't personally think of what it would be, it seems like really bad practice to be prescriptive about what keyboard controls people are allowed to use, and I don't know what else this feature is good for. ---- > That'd be great but there is no reason this couldn't be pursued as a separate layer on top of this instead of something that has to block it. I think my perspective is that I already do have this, it's my keyboard layout. Why are we taking away something that already exists and then reintroducing it as another separate layer that's optional? As a user, I want my keyboard customization to work in all apps, I don't want the developer to be able to override my preferences just because they don't feel like using them. It doesn't make sense to me that we'd get rid of a user-defined map that's currently working today, and then reintroduce it later.

zamadatix 5y ago

> But I've dealt with at least the first problem here, and I don't think that keymaps are necessarily the best way to solve it. Curious how you solved the WASD problem not if not by using a keymap in some way? > we should be coming up with a solution that maps to controllers as well The gamepad API already normalizes axes/buttons. > As a user, I want a user-controlled (or at least OS-controlled) layer between myself and app shortcuts/keycodes That'd be great but there is no reason this couldn't be pursued as a separate layer on top of this instead of something that has to block it. I doubt it'd get the same support though as it'd require a lot more "thou shalt do it this way" rather than "you can call this if you need" and such changes are much harder to get support for.

danShumway 5y ago
> Curious how you solved the WASD problem not if not by using a keymap in some way? Short answer, I just give the users an option to change their keyboard layout and use arrow keys/mouse as a backup for menu traversal in case they set their bindings weird and get stuck. For apps where that's annoying to prompt, I still provide the option but default to assuming QWERTY layout unless I see some signal (language options) that tells me I should more explicitly ask. Longer answer, I don't have hard stats and this is mostly just based on my intuition, but my feeling is: - QWERTY tends to be a pretty safe default for most US users, DVORAK tends to be either uncommon or the people using it already have custom maps set up, which I don't want to mess with. - Other layouts tend to be associated with other languages, so using `navigator.language` seems to be a decent proxy? At the least, if `navigator.language` says something other than "en-us", at that point I might decide to surface a prompt to pick a keyboard layout. - Users would rather be able to select their controls from a list (ie, have some keybinding "templates" or common schemes that players can toggle on) and then customize them, rather than have to build their control-scheme from scratch. ---- I do think it would be easier to have better defaults if I could look up the base layout from a list of common values and default them to a layout that's likely close to what they want. Something like `navigator.keyboard.getLayout` would be useful to me, similar to `id/mapping` on a gamepad. There are privacy risks there too, but I see the use case at least. But that's not really the same thing as wanting a map of every key, a map of every key is less useful to me than a string that says "DVORAK". It's also important to understand that displaying the key on the screen isn't actually the problem here; I don't really understand what the Github repo is talking about in that sense. Without the new API, the prompt you display on the screen will always be correct 100% of the time: if you tell the user to press the "W" key, they'll press the key they associate with "W". So the problem is not "how do I tell the user which key to press", it's "which key should the user press?" And in that situation all you're really looking for is the ability to set sensible defaults; I can't think of an example where I've wanted to be prescriptive about "the user must use their left hand to navigate, and it must be in the location of WASD". So I don't really know what I'd even use a full keymap for, the most I want is a signal for which pre-defined default keymap I should load up. I guess I can use `getLayoutMap` to do that, but it's clumsy and inflexible and requires extra coding: it's kind of an inferior solution to just giving me a layout string that I match against a table. Matching against a table based on ID/layout is also what I already do for controller defaults, so it's annoying to me to have a separate system somewhere else. ---- I mentioned "pits of success" above. There are a few traps and good practices when working with keybindings (opinion me). Some bad outcomes: - Not having rebindable keys or alternate layouts that the user can set. - Not respecting user-rebound keys (my caps lock is escape, I want that button to register as escape in everyone's web app). - Showing inaccurate information onscreen, telling the user to press "W" when you mean something else. Note that this is impossible to do without `getLayoutMap`, and very easy to do with `getLayoutMap`. Some positive results: - Having better default keybindings, as long as they can still be changed As far as I can tell, giving devs the option to ignore user keymaps and to use physical key positions for bindings makes it easier for them to fall into the first 3 traps, and only marginally helps with the second positive result. ---- Anyway, second TLDR, have some common layouts in your key rebinding options that people can quick-select (you probably should have this for WASD/arrow-key toggling anyway, not everyone on QWERTY layouts likes WASD). If you're worried about defaults, use `navigator.language` as a signal for whether you need to be more proactive about asking for the keyboard layout up-front. I also don't really understand what the Github repo is talking about when it says that displaying messages is hard, because as far as I can tell messages about what key to press are the only part of this that are currently impossible to break, and I'm a little annoyed Chrome has now made it possible to break them. Again, maybe there's something I'm missing, I assume devs have some reason for asking for this. I just can't personally think of what it would be, it seems like really bad practice to be prescriptive about what keyboard controls people are allowed to use, and I don't know what else this feature is good for. ---- > That'd be great but there is no reason this couldn't be pursued as a separate layer on top of this instead of something that has to block it. I think my perspective is that I already do have this, it's my keyboard layout. Why are we taking away something that already exists and then reintroducing it as another separate layer that's optional? As a user, I want my keyboard customization to work in all apps, I don't want the developer to be able to override my preferences just because they don't feel like using them. It doesn't make sense to me that we'd get rid of a user-defined map that's currently working today, and then reintroduce it later.