- From: Rowland Shaw <Rowland.Shaw@crystaldecisions.com>
- Date: Wed, 2 Oct 2002 23:59:44 -0700
- To: "'Philippe Le Hegaret'" <plh@w3.org>, Brad Pettit <bradp@microsoft.com>
- Cc: WWW DOM <www-dom@w3.org>
Philippe Le Hegaret [mailto:plh@w3.org] wrote... > On Thu, 2002-10-03 at 04:09, Brad Pettit wrote: > > I question whether it's appropriate for DOM to define > > as many virtual keys as it already does. Many of these > > keys are very device- or platform-specific. > > > > Also, you mention Unicode, which seems orthogonal to > > the discussion of virtual key codes. Aren't VK_ codes > > intended for key events and not character events? For > > example, there are not separate VK codes for '3' and '#' > > because they occupy the same key on the qwerty keyboard. > > Keycodes are device specific in any case so relying on them > for keydown/keyup would be inappropriate imho. Instead we > rely on the character that would be generated by pressing the > key. The specification is unclear however on which character > should be generated, i.e. with or without the modifier: > - A generates a 'a' on keydown/up, shift+A generates 'A'. > - 3 generates a '3' on keydown/up, shift+3 generates '3' (and not '#'). > Yet another inconsistency in the keyboard character system... In my opinion, the only sensible way, is that always the generated character would be generated. So in my case, shift+'3' will generate '£'. I think it's important that the users' locales are abstracted sufficiently so that we don't have to think, "ah yes, shift+3 is a currency symbol, so that's OK" In turn, this suggests to me that the best method is to return the (Unicode) character -- which a few virtual keys left over for non printing keys (for example, cursor, f-keys, esc, etc.)
Received on Thursday, 3 October 2002 03:03:08 UTC