A question about key identifiers on non-alphabetic keyboards.

[Hironori Bono (坊野 博典)]

Hi DOM3 Events folks,

Sorry for my question.
To read Section 6.2.6 of the latest draft, I'm wondering how we should
select key identifiers for a Russian keyboard (and ones for
non-alphabetics scripts).

On a Russian keyboard with a phonetic Russian mapping (*1), the key
labeled 'Q' (in terms of US 101 keyboard) maps to the key identifiers
'й' (U+0439) (unmodified) and 'Й' (U+0419) (modified).
To follow this step, when we type the key labeled 'Q' (in terms of US
101 keyboard) and a control key, a user-agent should generate a
keyboard event whose key identifier is 'й' (U+0439) and ctrlKey is
true.
On the other hand, I assume many web applications use the following
snippet to handle control-key events.

  if (evt.key == "Q" && evt.ctrlKey == true) {
    // ...
  }

So, straight-forwardly implementing this key identifiers may cause
compatibility problems that web applications don't work with Russian
keyboards (and ones for non-alphabetic scripts).

(*1) http://en.wikipedia.org/wiki/Keyboard_layout#Russian

The simplest workaround is changing the key identifier to 'Q' when we
type a control key. Nevertheless, it is probably not compliant with
this description.
Another workaround is that a user-agent maps such control keys to a
key identifier defined in Section 6.2.7. Nevertheless, this workaround
doesn't work with the above code.
(Even though using the legacy attribute 'keyCode' can avoid this
problem, it is inconsistent across platforms as written in Section
5.2.7.)

Would it be possible to give me advices about solutions for this problem?

Thank you for your help in advance.

Regards,

Hironori Bono
E-mail: hbono@...

[Doug Schepers-3]

Hi, Bono-san-

Hironori Bono (坊野 博典) wrote (on 9/24/09 1:17 AM):

> Hi DOM3 Events folks,
>
> Sorry for my question.
> To read Section 6.2.6 of the latest draft, I'm wondering how we should
> select key identifiers for a Russian keyboard (and ones for
> non-alphabetics scripts).
>
> On a Russian keyboard with a phonetic Russian mapping (*1), the key
> labeled 'Q' (in terms of US 101 keyboard) maps to the key identifiers
> 'й' (U+0439) (unmodified) and 'Й' (U+0419) (modified).
> To follow this step, when we type the key labeled 'Q' (in terms of US
> 101 keyboard) and a control key, a user-agent should generate a
> keyboard event whose key identifier is 'й' (U+0439) and ctrlKey is
> true.

Correct.


> On the other hand, I assume many web applications use the following
> snippet to handle control-key events.
>
>    if (evt.key == "Q"&&  evt.ctrlKey == true) {
>      // ...
>    }

The "key" attribute is defined in DOM3 Events, so I hope no code is
using that yet.  If it is, then we need to change the name of the
attribute, or it will conflict with existing content.

> So, straight-forwardly implementing this key identifiers may cause
> compatibility problems that web applications don't work with Russian
> keyboards (and ones for non-alphabetic scripts).
>
> (*1) http://en.wikipedia.org/wiki/Keyboard_layout#Russian
>
> The simplest workaround is changing the key identifier to 'Q' when we
> type a control key. Nevertheless, it is probably not compliant with
> this description.
> Another workaround is that a user-agent maps such control keys to a
> key identifier defined in Section 6.2.7. Nevertheless, this workaround
> doesn't work with the above code.
> (Even though using the legacy attribute 'keyCode' can avoid this
> problem, it is inconsistent across platforms as written in Section
> 5.2.7.)
>
> Would it be possible to give me advices about solutions for this problem?

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]
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyboard-layout
[2] http://www.iana.org/assignments/language-subtag-registry


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

[Hironori Bono (坊野 博典)]

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

Regards,

Hironori Bono
E-mail: hbono@...

On Fri, Sep 25, 2009 at 6:24 PM, Doug Schepers <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]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyboard-layout
> [2] http://www.iana.org/assignments/language-subtag-registry
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

[Doug Schepers-3]

Hi, Bono-san-

Hironori Bono (坊野 博典) wrote (on 9/27/09 11:35 PM):
>
> Thank you so much for your answers.

あなたを歓迎している


> They are definitely helpful for me to write automated tests for this
> 'key' attribute.

We will need to create a test suite for the DOM3 Events specification,
so please consider donating you tests to the WebApps WG.  We would be
very grateful.


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

Yes, we will keep working on this problem.  I think it is out of scope
for DOM3 Events, but I hope we can solve this in a later specification.
  I have been reading quite a lot about keyboards lately with that goal.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs