RE: Key Events internationalization

Please check my understanding below, and the question that follows:

So, as I understand it, the implementation can interrogate keyboard mapping
tables to find out what functions/characters are associated with a given
physical key at any given time (since keyboard mappings can be changed at
any time).

For keys that are functionally oriented, such as arrow keys, page down, F5,
etc, the implementation can choose an identifier to represent a key from the
list of suggested identifiers such as "Right", "PageDown", "F5", etc.  

Other keys are typically used to input characters, and these are the ones
that typically vary in effect when different keyboard mappings are used for
typing text (eg. Serbian or Dvorak kbds produce different textInput results
for the same physical key).  

For these keys, the implementation, by using the keyboard mapping table, can
detect the characters potentially produced by a given key, and from that set
of characters the implementation can choose one Unicode code point to
represent the key. For example, the key with Q on it on a US keyboard may be
called "U+0051". 

Furthermore, this key is referred to with the same key identifier whether
pressing it produces a textInput result or not - eg. Ctrl+Q won't produce a
textInput result, but the same identifier would be returned by keypress when
the Q key is pressed. 
The same identifier, ie. "U+0051", would also be used to identify that
physical key even if it is pressed in conjunction with, say, the shift key
(which would produce a textInput result that is a totally different
character).

Content authors would then be able to fire actions based on events
associated with the press of a particular key, as long as that key was
associated with a given character in the keyboard mapping tables.  

For example, in the Bloglines beta, pressing the 's' key will advance you to
the next feed. Let's assume that Bloglines looks for a keydown event to
trigger this.

On my US-manufactured physical keyboard, and with a standard US keyboard
mapping in place, that would mean me pressing the key engraved with S. 
However, if I change my mapping to a Dvorak keyboard (but don't change my
web page), I'd need to press the physical key engraved with ;/: to achieve
the same result (that's the key that now produces s/S in typing).  
If I change my keyboard mapping to a Serbian keyboard, I wouldn't be able to
match the keydown to an action at all, because none of the keys on the
keyboard, and therefore none of the key identifiers produced by key presses,
are now associated with the letter S.  (Presumably, I'd need a Serbian
localized version of Bloglines that was expecting Serbian keystrokes to fire
actions.)

Please let me know whether I'm on the right track above - especially wrt a
single keyIdentifier being produced per physical key.


If the above is all correct, I guess that I have the following initial
question:

I assume that one goal of using key identifiers is to have a standard way of
referring to the press/release of a given key across user agents.  I don't
however see any suggestions for how to choose one among the set of
characters potentially produced by a key.  The guidelines for defining key
identifiers seems to indicate that "U+0051" (LATIN CAPITAL LETTER Q) is a
good choice for the physical key engraved with Q on a US PC/AT keyboard.
U+0051 is the character generated by that key with the shift key pressed on
such a keyboard. But for a key engraved with 1/! the document suggests
"U+0031" (DIGIT ONE) - this being the unshifted result of that key.  

Is there an implicit convention that where no-shift and shift produce
respectively lower and upper case characters in typing from the same key, an
implementation should produce a key identifier associated with the upper
case letter, whereas if there is no upper vs lower case correspondance the
implementation should produce a key identifier that is associated with the
unshifted result when typing text for a given keyboard mapping? (And does
this convention related to uppercase extend to Cyrillic, Armenian and Greek
keyboards?)

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
 
 

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
> Sent: 30 August 2007 12:20
> To: Richard Ishida
> Cc: public-webapi@w3.org; public-i18n-core@w3.org
> Subject: Re: Key Events internationalization
> 
> * Richard Ishida wrote:
> >Oh.  So there is a plan to specify those? If so, how would 
> they differ 
> >from the .keyIdentifier, and what is .keyIdentifier for?
> 
> The Working Group resolved to specify them, yes. But so far 
> nobody has been able to come up with a specification, largely 
> because they are not particularily interoperably or 
> meaningfully implemented.
> 
> The .keyIdentifier attribute on KeyboardEvent objects 
> identifies the key associated with the event object. Without 
> a specification for .charCode and .keyCode, I can't really 
> say what the difference is.
> 
> >> Instead the appendix discusses the .keyIdentifier attribute.
> >
> >So were/how does the .keyIdentifier attribute get its information?
> 
> The DOM implementation is responsible for setting the attribute.
> The implementation would get the necessary information from 
> its runtime environment. For a low-level description you 
> might try 
> http://en.wikipedia.org/wiki/Computer_keyboard#How_it_works 
> and 
> http://en.wikipedia.org/wiki/X_Window_core_protocol#Mappings 
> for a higher-level description. I am not sure what you really 
> want to know here.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · 
> http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: 
> +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 
> http://www.websitedev.de/ 
>

Received on Monday, 17 September 2007 16:54:40 UTC