- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 30 Jun 2008 10:21:06 +1000
- To: Doug Schepers <schepers@w3.org>
- Cc: public-webapps@w3.org, public-i18n-core@w3.org
Hi Doug. Doug Schepers: >>> Converting to uppercase strikes me as needless legacy from >>> keyCode/charCode. Is there some pragmatic reason to force this >>> casting? Cameron McCormack: >> These strings are meant to represent keys, rather than characters of >> input. Doug Schepers: > 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. You’re saying that the alphabetic keys on western keyboards are mislabelled with uppercase letters, when they should have lowercase letters on them? I think it’s just a styling issue, really. I could live with the key identifier being the lowercase letter, but given that we should choose one or the other, the uppercase letter is more consistent with the other identifiers (none of which start with a lowercase letter). > 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. The only reason for including a key identifier for "!" would be if there were a keyboard that had a key whose primary function is to generate a U+0021 character. On my QWERTY keyboard, I wouldn’t expect the "!" key identifier ever to be used in a KeyboardEvent (instead, the "1" key identifier would be used, and shiftKey would be true). > 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. I agree that the key is acting like "q|Q". I would only agree that there should be identifiers for both "q" and "Q" if there are likely to be keyboards that have a key whose primary function is to generate an uppercase "Q" character. I don’t know of such a keyboard, but perhaps we don’t want to rule this out, in which case I would advise using the lowercase letter as the key identifier. > 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. Of course, but there is already wording in that algorithm to take the keyboard layout mapping into account. > 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. It’s not what is printed on the keycap that is important, but the function of the key subject to the keyboard layout mapping. But we are trying to identify a single key, and not what functions it may have under different modifiers, yes? -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 30 June 2008 00:21:58 UTC