Re: A question about key identifiers on non-alphabetic keyboards.

Hi Doug,

Thank you so much for your answers.
They are definitely helpful for me to write automated tests for this
'key' attribute.

As for the solutions for this problem. I'm also sorry I don't have
good solutions for this problem, either. Nevertheless, I wish we can
cooperate to provide them to web application developers. (I think many
great engineers also read this ML. So I hope they also provide good


Hironori Bono

On Fri, Sep 25, 2009 at 6:24 PM, Doug Schepers <> wrote:

> It seems you're asking how an author can try to rely on a particular
> physical layout and key mapping to "identify" a particular key, and the
> answer is, unfortunately, you can't. The spec talks a bit about this [1].
> You can guess, using keyCode, but that's not any guarantee (as you note).
> You might be able to approach it a bit more robustly, as an author, by not
> using specific key identifier string literals, and providing a variable
> "hotkey" map instead, initializing each hotkey to what you think is the
> appropriate value using language subtags [2] (e.g. if
> navigator.systemLanguage == "ru", quit = ""; if evt.key == quit &&
> evt.ctrlKey == true ... ). But even then, you're guessing that the user is
> using a standard keyboard mapping... for example, with the Dvorak mapping,
> hitting the key immediately to the left of the tab key will give you a
> double-quote, not "q", and the user could be using a custom mapping as well,
> with any language.
> The safest way right now is for the webapp to simply provide a means for the
> user to choose their own hotkeys. This also ensures that the webapp isn't
> overriding existing hotkey functionality.
> I've been thinking a lot about this, actually, and the only solution I have
> come up with is likely too over-engineered. If the OS would expose the
> physical layout and mapping information to the browser, the author could use
> a reference keyboard layout (like ISO/IEC 9995) in combination with key
> identifiers to indicate which *physical key* they want to use as for
> particular input, and the browser would map that to the event.key. It
> should work, but it would probably need to be specified somewhere, and
> implemented, and it would take a while to deploy. (I think this may be
> similar to one of your suggestions above.)
> I'm sorry I don't have a better answer for you. I believe the original
> editors of DOM3 Events tried to meet this use case, but in the end, I don't
> think key identifiers alone can do this.
> If people have other suggestions, especially elegant ones that could be
> included in DOM3 Events, I would very much welcome them.
> [1]
> [2]
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Received on Monday, 28 September 2009 06:35:49 UTC