W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: ACTION-25: Make a proposal for the additions that the mobile folks have been asking for in keyboard events

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 15 Apr 2006 16:02:18 +1000
To: Public Web API <public-webapi@w3.org>
Message-ID: <20060415060217.GA12255@port.mcc.id.au>

Hi Robin.

Robin Berjon:
> : New Key Identifiers

I have to say that I agree with Ian, too.  I don't see any benefit from
having these as separate key identifiers unless you know of input
devices that have both the traditional arrow keys and the joystick
buttons, since, as Ian said, using common key identifiers will allow
scripts to work with keyboards and mobile keypads.

What about using KeyboardEvent.keyLocation to distinguish these two?
DOM_KEY_LOCATION_NUMPAD could be used for the joystick presses (the
mobile keyboard is sort of like the numpad on a computer keyboard).

> : Reporting longpress
> 
> A new key modifier is introduced, called LongPress. It should be  
> added to the list given in getModifierState(), and it can naturally  
> be used in the modifiersList argument of initKeyboardEvent*(). Since  
> that doesn't necessarily make it sufficiently explicit to authors, an  
> informative paragraph should be added to appendix A (see below).

Is this how keypresses are reported by the mobile devices?  If so, then
this seems ok to me.  Should UAs set this modifier for non-mobile input
devices (such as regular keyboards)?  I guess key repeat and long press
are mutually exclusive, and I wonder at what point in the chain of
device---OS---UA this is/should be handled.

> : Nicer key identifiers
> 
> It has been suggested that since mobile keyboards have a pretty much  
> universal set of 12 keys in common, it would be nice for authors if  
> those were given identifiers friendlier than "U+0030" through "U 
> +0039" (0-9), "U+0023" (#) and "U+002A" (*). I don't have a strong  
> opinion, though I do agree that it would simplify matters. The  
> following list could therefore be added (maybe calling them Dial*  
> would be more informative than Key* given this is about keys in the  
> first place, but using variants on a "key" prefix seems common in the  
> industry):

If these are equivalent to U+0030 to U+0039 then they certainly
shouldn't be prefixed with Dial, since that's not appropriate for
computer keyboards.  If you wanted to avoid the "U+...." naming scheme
for the key identifiers altogether, the "Guidelines for defining key
identifiers" section could be rewritten to achieve this.  Actually, I
would prefer this.  Currently the only requirement is that the
identifier not include any whitespace.  I don't see any problem with
using the actual characters (for those keys that map to non-control
Unicode characters and aren't combining characters).

  A.1.5 Guidelines for defining key identifiers

  The list of key identifiers contained in this appendix is not
  exhaustive and input devices may have to define their own key
  identifiers. Here is a algorithm to determine which key identifier to
  use:

    1. Consider the primary function of the key (i.e., without
       modifiers), taking into consideration the keyboard layout mapping
       in use, to determine if a corresponding Unicode character exists
       from which a key identifier may be derived.  If there exists
       multiple Unicode characters that correspond to the primary
       function of the key, the Unicode character with the lowest
       codepoint must be used.

       1.1. If the primary function of the key is to generate a
            character, and that character is in one of the Unicode
            general categories Lu, Ll, Lt, Lm, Lo, Nd, Nl, No, Pc, Pd,
            Ps, Pe, Pi, Pf, Po, Sm, Sc, Sk or So, then the key
            identifier is a string consisting of just that character.
            If the primary function of the key is to generate a
            character in class Ll for which there exists an equivalent,
            single character in class Lu, the uppercase character should
            be used instead.
        
       1.2. If the primary function of the key is to generate a
            character that is not in one of the above general
            categories, or if the primary function of the key is a
            function for which there exists a corresponding Unicode
            character that is not in one of the above general
	    categories, then:

            1.2.1. If there exists an appropriate key identifier in the
                   list in section A.2 below, that key identifier must
                   be used.

            1.2.2. If there is no appropriate key identifier in A.2, 
                   then the key identifier is a string beginning with
                   "U+" and followed by the Unicode codepoint of the
                   character in hexadecimal, using at least four digits.
                   Leading zeroes must be omitted unless they are
                   required to make the codepoint use at least four
                   digits.

    2. For keys with no corresponding Unicode character, a key
       identifier can be devised.  The key identifier should be as human
       friendly as possible and must not contain whitespace.  The
       identifier must be composed only of characters in the ranges
       U+0030..U+0039, U+0041..U+005A, U+0061..U+007A and must begin
       with a character in the range U+0041..U+005A.

  Examples:

    * On a PC/AT US keyboard with a US keyboard mapping, the primary
      function (unmodified) of the 'Q' key is to generate the character
      U+0071.  Since this character is in general category Ll, and there
      is a single corresponding character in Lu, U+0051, this character
      is used instead.  Thus, the key identifier is "Q".

    * On a PC/AT US keyboard with a two-handed Dvorak keyboard mapping,
      the 'Q' key maps to the '5/%' key.  The primary function of this
      key is to generate the character U+0035.  Since this character is
      in general category Nd, the key identifier is "5".

    * On a French PC keyboard with a standard French mapping, the primary
      function of the '^' key is as a dead key for the circumflex
      diacritical mark.  This corresponds to the combining Unicode
      character U+0302.  Since this character is in general category Mn,
      the key identifier is "U+0302".

    * On a Korean PC keyboard with a standard Korean mapping, the
      primary function of the 'Ha/En' key is to switch between Hangul
      and English input.  The predefined key identifier list has an
      appropriate entry for this key, "HangulMode", so this is the key
      identifier.

    * On some models of PDAs, the primary function of the key with a
      picture of a calendar on it is to launch the calendaring program.
      Since there is no Unicode character that corresponds to this
      function, and there is no appropriate entry in the predefined key
      identifier list, an new identifier can be devised, such as
      "Calendar".

It may be a good idea to survey recent phone and PDA models and include
some extra key identifiers in the list to avoid different names being
invented for the same key.

Cameron

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org
Received on Saturday, 15 April 2006 06:02:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT