Re: Proposal to add USB keycodes to the current DOM3 key events

An administrivial point - rather than adding to DOM 3 Events (which is  
essenially a legacy spec being standardised for information, rather than  
the future...) I believe this discussion should assume we are talking  
about DOM4 or a new spec.

More substance below...

On Thu, 13 Sep 2012 03:15:16 -0400, Masayuki Nakano  
<masayuki@d-toybox.com> wrote:

> Hi, I'm a developer of Gecko. So, I'd like to comments to this document.
>
> On 2012/09/08 3:37, Gary Kacmarcik (Кошмарчик) wrote:
>> Problems with the current DOM Level 3 key events
>> ================================================
>>
>> Problem 1: Matching keydown and keyup events
>> --------------------------------------------
>>
>> The main problem with the current proposal is that it doesn't provide
>> enough information so that keyup events can be matched with their
>> corresponding keydown event. In this regard, it is unlike the legacy
>> events, where the keyCode value was usually sufficient to match the
>> keydown/keyup events.
>
> Yeah, but there are some cases that only keydown or only keyup event is  
> fired.

Yes...

> * If a utility software or IME generates fake native key event to the  
> browser, it may cause only keydown or keyup event if the native key  
> event isn't one or more sets of native keydown and keyup events.

Right. Which is an issue...

> So, anyway, it's very difficult issue to know if a key is actually  
> pressed.
>
>> For examples of why this is a problem, consider the following scenarios:

>> * Applications that provide remote access functionality often need to
>> keep track of the sequence of events that generated a particular
>> character. This is so that they can handle the case where the local
>> and remote systems have different keyboard layouts (since they may
>> require a different sequence of keys or modifiers to be injected on
>> the remote machine).
>
> I don't understand this case. I think that applications should prefer  
> the actual key event's information rather than the different keyboard  
> layout...
>
>> Problem 2: Identifying keys by their position
>> ---------------------------------------------
>>
>> While not as critical as the first problem, another common task for
>> some applications (typically games) is to handle key events based on
>> the key's position on the keyboard. For example, a game may want to
>> detect when the key next to the CapsLock key is pressed so it can be
>> associated with some player action. With a US keyboard, this would be
>> the key with the 'A' keycap, but on an AZERTY keyboard, this key would
>> have a 'Q' keycap.
>>
>> A layout-independent way of identifying keys would be useful to games,
>> music/beatbox players, and other apps that prefer to consider the
>> keyboard as a set of buttons. A touch-typing app could also use
>> information to this target lessons for the home row or for the
>> left/right hand.
>>
>> (Note that some implementations of HTML4 key events suffer from this
>> problem as well. For example, the keycodes in WebKit-based browsers
>> are based on Windows VKEY values, which are layout-dependent.)
>
> I don't agree with this idea. I think that if games want to use  
> different keys on different keyboard layouts as same key, games should  
> provide the key configuration UI with some presets for major keyboard  
> layouts.

Right. The desktop keyboard case isn't so bad, but on-screen keyboards for  
english and russian tend to have completely different layouts (because  
they are not using a fixed number of keys), and IMEs get more complicated  
before you even get to input from speech systems and other control  
mechanisms.

There is an "anti-pattern" here, using javascript to find out about a  
physical keyboard, that is very common but problematic (because it makes  
assumptions about the user and their system that are increasingly untrue).  
While I understand the strong motivation for it, rather than making it  
easier to do the wrong thing I'd really like to see us taking on a  
proposal that deals with these outstanding issues...

I realise I am opening myself up to the action item of "doing something  
instead of just complaining". I am afriad it won't be completed today, but  
I do expect to follow up. It's likely to involve looking at the ideas  
behind IndieUI, accesskeys and command elements in HTML5, and similar  
things that *do* point in the right direction but which have the real  
shortcoming that they have gained limited traction.

> But I do *not* object to following suggestion since there might be  
> useful cases which I've never realized.
>
>> Proposal
>> ========
>
>> A more complete mapping table between USB usage codes and
>> platform-specific scancodes can be found in the Chromium source code
>> at:
>> http://code.google.com/searchframe#OAMlx_jo-ck/src/ui/base/keycodes/usb_keycode_map.h
>
> That's interesting. But how should it behave with software keyboard on  
> mobile device?

Yes, this is likely to be a serious issue in some cases. Although I doubt  
it for the game case where current practice would be to also have a series  
of buttons and events or something as an alternative UI...

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 13 September 2012 14:47:18 UTC