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

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