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

Hi, Cameron-

CCing i18n folks; for reference, please see:
   http://www.w3.org/2008/webapps/track/issues/23

Cameron McCormack wrote (on 6/29/08 3:47 AM):
> Web Applications Working Group Issue Tracker:
>> In the current draft of Key Identifiers, including the new algorithm
>> wording, there is a bias toward uppercase characters. Essentially, if
>> a key is pressed that gives a character codepoint which is lowercase,
>> for which there is an uppercase equivalent, the uppercase codepoint
>> (or character) is returned instead. What is the use case here?
> 
> The intention of that algorithm (if I remember my intention correctly
> when writing it) is to provide guidance for implementors in choosing a
> key identifier for a given key.  For example the 'A' key on many
> keyboards (like QWERTY) has a primary function (i.e. without modifiers
> pressed or locks enabled) of generating an 'a' character.  Given that
> keyboards usually have the uppercase character printed on the keys,
> using 'A' seemed to be nicer than 'a' as a key identifier.
...
> I’ve yet to see a keyboard that has a key for lowercase 'q' and
> uppercase 'Q', so I don’t know that it makes sense to have two different
> key identifiers for them.  Given the fact that the 'U+0051'-style of key
> identifier is awkward, we should choose either 'Q' or 'q' here.
> 
>> Converting to uppercase strikes me as needless legacy from
>> keyCode/charCode. Is there some pragmatic reason to force this
>> casting?
> 
> These strings are meant to represent keys, rather than characters of
> input.

A reasonable argument, but I would counter that the keys are simply 
mislabeled, because of long-ago imprecision on typewriters that we need 
not perpetuate.  The identity of the key is not what is printed on the 
keycap, but what the operating system thinks the key is, at the time 
that the key is pressed.

When I hit the key labeled "1" on my keyboard with no modifiers, it 
generated the character "1" (intuitive enough); with the "shift" 
modifier, it generates the character "!".  Both of those characters are 
printed on the key, as it happens: "1|!"; the key identifiers set 
naturally includes both characters.   By contrast, when I hit the key 
labeled "Q" on my keyboard with no modifiers, it generates the character 
"q", and only generates the character "Q" when it is modified with 
"shift" or "capslock".  So, really, the label should read "q|Q", and we 
should provide key identifiers for both upper- and lower-case characters.

Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the 
labels on the keys remain unchanged, a typist would expect that hitting 
the key labeled "Q" would result in an apostrophe... they would expect 
the same behavior if they had bothered switching the keycaps, as well as 
remapping.  If they were asked to type "Q" or "q", they would naturally 
hit the key that, on my keyboard, is labeled "X".  The same goes for any 
remapping, such as when an US keyboard is repurposed to some other alphabet.

We've already determined that we can not and should not identify a key 
by keyboard layout, i.e. the physical position of the keys; the same 
applies to what is printed on the keycap, even more so.

If the Director deems it necessary, in the course of Rec-track 
transition, for DOM3 Events to represent only the values that are 
printed on the keycap, I will take an action to go door-to-door and 
manually correct each keyboard (by force if necessary).  I am aware that 
this may take some time (even weeks, perhaps), but I believe that that 
would be a more logical and pragmatic approach than for DOM3 Events to 
munge all Latinate characters into the uppercase.  We all know that 
typing in all caps is rude, and forcing all keyboard events to SHOUT 
would degrade the bounds of polite society.

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

Received on Sunday, 29 June 2008 20:05:10 UTC