W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2008

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

From: Andrew Cunningham <andrewc@vicnet.net.au>
Date: Mon, 30 Jun 2008 15:22:26 +1000
Message-ID: <48686D92.2070401@vicnet.net.au>
To: public-webapps@w3.org, public-i18n-core@w3.org, Andrew Cunningham <andrewc@vicnet.net.au>


Cameron McCormack wrote:

> Andrew Cunningham:
>   
>
>> 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.
>   
ok, so more of a mnemonic approach, as far as i can tell.

I'd assume that you'd need to know what keyboard layout is currently 
being used in order to know what key identifier is being dispatched. 
What happens if the keyboard layout can't be identified? I'm using 
Windows Vista (International English) with an input locale set to 
English (Australian), the physical keyboard is QWERTY (US layout), but 
the keyboard layout i'm typing with is something completely different.

How would a web application know if typed "q"? since "q" isn't assigned 
to level one of the layout I'm using? I can see how it can know i 
pressed a key that generated a scan code that signified a "q" key on a 
QWERTY keyboard, but without looking at the output how would the 
application actually know?

I input locale would imply that i'd used a key associated with key 
identifier "q", but if I understand what you mean correctly, I've 
actually typed the key associated with key identifier "ŋ". If this makes 
sense

Just trying to figure out how African or South East Asian keyboard 
layouts would work, esp. visual rather than logical keyboards, where the 
order of keystroke and character output may be different.

What would happen if the key identifier was a combining diacritic or a 
Myanmar medial character? would that be ok? could be some interesting 
text rendering issues within code, or the need to develop very 
specialised fonts specifically for writing code for web applications.

Are there restrictions on the names of key identifiers?

And would this mean there is a restriction on what keys can be used 
within a web application?

>
>> 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”?
>
>   
yes

-- 
Andrew Cunningham
Vicnet Research and Development Coordinator
State Library of Victoria
328 Swanston Street
Melbourne VIC 3000

Ph: +61-3-8664-7430
Fax: +61-3-9639-2175

Email: andrewc@vicnet.net.au
Alt email: lang.support@gmail.com

http://home.vicnet.net.au/~andrewc/
http://www.openroad.net.au
http://www.vicnet.net.au

http://www.slv.vic.gov.au


Received on Monday, 30 June 2008 05:23:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:55 GMT