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
