- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 30 Jun 2008 12:22:04 +1000
- To: Andrew Cunningham <andrewc@vicnet.net.au>
- Cc: Doug Schepers <schepers@w3.org>
Hi Andrew. Andrew Cunningham: > Out of interest, how does the algorithm take that into account. > > for my default layout the keystrokes that normally produce q|Q produce > ŋ|Ŋ inɛtead, and i need to type AltGr+q/AltGr+Q to get q|Q As it’s currently written, the key identifier would be "Ŋ", since "ŋ" is in general category Ll, and it has a single character uppercase equivalent "Ŋ". > my system input local is en-AU, keyboard driver is customised to > specific African languages, and physical keyboard is standard qwerty. What is the difference between the system input locale and the keyboard layout? What does the customised keyboard driver do? > I'm curious how the algorithm will handle undefined input locales, or > keyboard drivers that are forced to use the wrong input locale (which in > theory is most of the languages in the world at the moment). I’m not sure what an undefined input locale is, or the keyboard driver issue. Could you explain? > As far as i can see there is no way for an application to know what > keystrokes are being used and extrapolate what character was intended > from the sequence, esp. if more sophisticated processing and reordering > is occurring within a driver before the character is past to an > application. I agree that there is a level below which normal applications will not be able to look. For example, if a device driver is converting all “Caps Lock” key press events on an Australian QWERTY keyboard to “Control” events and vice versa, then there’s nothing the application can do to determine which physical key was pressed. But if the driver is doing that, then that’s pretty much equivalent to having a keyboard layout in use that generates those swapped key events at the application level. I think it is the events at this level (application) that we want to use for the DOM 3 Events key identifiers. > At best you might be able to determine what keystrokes are used (maybe > not always) and what characters are ultimately generated, although > characters generated may not be in the same order as keystrokes that > generate those characters. I think for these key identifier strings we shouldn’t be worrying about what character input is then generated and passed to the application, since that’s the job of TextEvent. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 30 June 2008 04:18:25 UTC