W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2008

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

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>
Message-ID: <20080630022204.GB14064@arc.mcc.id.au>

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:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:55 GMT