> Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything.

I think there's a really tangible difference between saying that AZERTY layouts prefer to use ZQSD for layout and saying that everyone is going to use the four keys on the left-hand side of the screen.

It's sort of the same situation as controllers -- using physical maps to standardize controllers is just flat-out wrong, because different controllers have different conventions about what buttons in the same physical locations should commonly do.

It's fine to say that there are common layouts that have defaults, but I think it's a much larger step to say that shortcuts/keybindings should be defined by physical location rather than convention. I don't completely see how that makes thing simpler for me as a developer (I don't want to intuit keyboard layouts by iterating over keys), and certainly I don't want it as a user.

----

> It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg

I have some other objections to your points below this (allowing applications to override user preferences is in fact a loss in user functionality, even if developers aren't forced to ignore those preferences), but I want to really focus in on this specific example, because you're not the first person I've seen bringing this up as a problem that needs to be fixed. And honestly, I really don't understand at all what people are talking about with this "fixing keymap messages" thing. I don't think I've ever had a problem with this[0].

Under the current scheme, before Chrome introduced this feature, it was impossible for a developer to mess this up. If you told the user to press "Z", and they pressed the key that they normally press to get "Z", no matter what their layout was or what their keyboard looked like your app would register a "Z" press. Whatever key you told them to press, if they pressed it you got that key. Perfect, impossible to break.

But if you now are basing your prompts on a keymap that bypasses the user's keyboard layout and uses the physical position, and still labels those keys based on a QWERTY layout, then it is now possible to break the message and to tell the user to press the "Z" key, and then to have the "Z" key not work because what you're listening to is the physical location of the "Z" key on a QWERTY layout rather than the key that they use in their layout for typing a "Z".

So I don't really understand what people are talking about with this objection; Chrome isn't fixing anything about user prompts because nothing needed to be fixed about matching user prompts to keybindings, it worked 100% of the time. The new feature actually breaks that and makes it possible to now implement user prompts that are inaccurate.

I believe people who say they have struggled to implement this in the past, they wouldn't lie to me, but... for the life of me, I can't imagine how they're implementing keybindings then; I'm not sure what I could do architecturally to make inaccurate user prompts about keycodes into an issue for a webapp.

----

[0]: Okay, that's not quite true. I did have a problem with this once on a controller that mapped keys based on their physical location. The only time this has been a difficult problem for me to solve was when I was trying to figure out controller layouts and I realized that the letter painted on the controller button wouldn't consistently match up with the keycode across controllers.