title: How do international keyboards work with JavaScript keyboard events?
body: <p>I've written <a href="https://www.primroseeditor.com" rel="nofollow">a text editor in JavaScript that draws directly to a Canvas element</a> (for various reasons, but my primary reason is so I can slap that canvas onto a WebGL mesh as a texture). As a happy surprise, it's been easier to implement that any content-editable solutions I've found.</p>
  
  <p>One thing I noticed early on were complaints from people with keyboard layouts other than en-US QWERTY that some keys were showing an incorrect letter. After some fiddling around with Windows' language settings and on-screen keyboard, I created a code-page based solution that maps keyCodes to character-strings for different locales directly, rather than just assuming "keyCode 51 with no modifier keys is the number 3". Because it's not, on some keyboards it's double-qoute.</p>
  
  <p>But there are still some oddities. A few examples (note that all of these examples are based on using the Windows on-screen keyboard, so I'm only assuming this correlates with reality):</p>
  
  <ul>
  <li>The <strong>French AZERTY</strong> keyboard sends a keyDown and keyPressed events when a letter U is typed, but never a keyUp. I'm assuming U must be need to be combined with another key, but not knowing what the correct behavior should be is preventing me from writing the right code. <em>EDIT: I still haven't quite figured out what this means, <a href="http://en.wikipedia.org/wiki/AZERTY#Missing_elements" rel="nofollow">other than--perhaps--that key is only used in one word the entire French language?</a></em></li>
  <li><strike>The <strong>German QWERTZ</strong> keyboard has a ^ (it's not a caret, it looks larger) key where the ` (backtick) key would be on the US keyboard, and a backtick key where the = (equals) key would be on the US keyboard. In both cases, they send keyDown and keyUp events, but do not appear to print anything in any text editor I use, until they are hit a second time, and then two characters are printed. Is this something to do with combining marks? I can't find anything about it.</strike> <em>EDIT: <a href="http://en.wikipedia.org/wiki/Dead_key" rel="nofollow">These are called dead keys</a>, and they create accented letters. A lot of keyboard layouts have them. I'll create a key-sequencing system for this that will also help provide support for more complex, Emacs-style keyboard shortcuts, if any are chosen.</em></li>
  <li><strike>The <strong>UK QWERTY</strong> keyboard has a backslash that requires use of an ALT-GRAPH key (Right-Alt key on US keyboards). There is a <strong><a href="https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.location" rel="nofollow">location property of KeyboardEvent</a></strong> that could be used to determine which of the ALT keys are pressed, but it apparently isn't available in Safari. This is pretty low priority, as Safari typically only accounts for 1% or less of my traffic. However, is there a property that works for Safari that I can use as a fallback?</strike> <em>EDIT: I'll handle this as the rest of my code-page system works for the differences between lower- and upper-case keys. It's just a different code page for a new modifier key. I'll have to change how the modifier keys are detected, but it's a minor change and will actually fit into the keyboard shortcut system quite easily.</em></li>
  <li>Finally, judging from the Windows' language settings, there are a lot of different keyboard layouts in the world. Is there any listing of the keycodes and behaviors anywhere? I'd rather not have to manually test every keyboard just to generate a new code-page for them.</li>
  </ul>
  
  <p>The first two problems are the biggest. I can figure out a solution to these if I just know what the behavior is supposed to be. The third issue will fit into my code-page system, though I'll have to change how I read modifier keys. The final issue, I could probably pay someone to cover.</p>
  
  <p>And I'm fine with not being able to solve it for all users in all browsers 100% of the time. But most of the information I've ran across is basically "don't bother", which really only sounds more like "I don't know".</p>
  
  <p><em>EDIT: selecting the layout isn't a concern. I provide it as an option to the user, if things aren't working for them. I think that's about the best thing one can do in this situation, but obviously I would auto-detect if I could. I'm really only concerned with getting the right behavior given that the right layout has already been chosen.</em></p>
  
  <p><em>I would like to avoid anything involving the keyPress event, given that it isn't perfectly reliable. If I had a reliable source of data on keyboard layouts, it wouldn't be an issue.</em></p>