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
<[email protected]> 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
[email protected] Find more at http://yandex.com
