Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]

Andrew Cunningham:
> It sounds confused to me, as far as i can tell you're trying to use  
> positional keyboard concepts in a mnemonic way.

It’s quite possible I’m confused. :)

> A q|Q on a QWERTY keyboard will have different scan codes and virtual  
> key codes that the q|Q key on an AZERTY keyboard.

Even when the AZERTY keyboard is being used with an AZERTY keyboard
layout chosen in the OS?

> so if you want a q|Q key on a US keyboard or a French keyboard to do the  
> same thing on a web app, you're talking about a higher level  
> interpretation of what a keyboard is doing. I.e. you're looking at  
> output rather than at physical keys.

I think what we want is the level just underneath the IME.  (Current
editors of the DOM 3 Events spec, chime in if that’s not correct.)  To
take a couple of examples:

Using a QWERTY keyboard with a QWERTY keyboard layout chosen in the OS:

  ▪ Regardless of the locks enabled or modifiers pressed, pressing the
    key labelled "Q" would result in a KeyboardEvent with key identifier
    "Q" being dispatched.

Using a QWERTY keyboard with an AZERTY keyboard layout chosen in the OS:

  ▪ Regardless of the locks enabled or modifiers pressed, pressing the
    key labelled "Q" would result in a KeyboardEvent with key identifier
    "A" being dispatched.

Using a AZERTY keyboard with an QWERTY keyboard layout chosen in the OS:

  ▪ Regardless of the locks enabled or modifiers pressed, pressing the
    key labelled "Q" would result in a KeyboardEvent with key identifier
    "Q" being dispatched.

It might be the “regardless of keyboard locks enabled” bit that is
tripping me up, though.  Taking another example of using a standard
Korean keyboard (called Dubeolshik (두벌식) according to the wikipedia
article I’m looking at) with the corresponding keyboard layout chosen in
the OS:

  ▪ Pressing the key just to the right of Tab would generate a
    KeyboardEvent with key identifier "ㅂ", since that key’s primary
    function is to generate the ㅂ jamo.  If Shift were pressed at the
    same time, you would still get "ㅂ" rather than "ㅃ".

But now what if the Ha/En key were pressed before pressing that key to
the right of Tab?  Should we consider this key just like caps lock (so
that pressing the key to the right of Tab still generates a "ㅂ" instead
of a "Q" key identifier)?  Or should we consider that the keyboard
layout has actually changed, and so use "Q"?

> unless i'm misunderstanding what you're trying to do.

Perhaps I should get confirmation from the other people working on DOM 3
Events about what exact KeyboardEvent is meant to be. :)

> if you want input locale independent nomenclature for the keys, then  
> maybe use ISO-9995 based terminology, but that's all positional. So are  
> most virtual key naming conventions I've come across.

Positional being things like “the third key on the second row”?

>> Do you mind if I forward this exchange back to public-webapps and
>> public-i18n-core?
>>   
> yes, feel free. I'm on the public-i18n-core list.

Done.  If you could include those two lists in any reply that’d be
helpful.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 30 June 2008 04:51:54 UTC