> 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.