Re: [DOM3Events] Comments on DOM Level 3 key events

On 09/25/2012 06:00 PM, Gary Kacmarcik (Кошмарчик) wrote:
> Problems with the current DOM Level 3 key events
> ================================================
> 
> Problem 1: Matching keydown and keyup events
> --------------------------------------------
> 
[...]
> 
> \\
> Problem 2: Identifying keys by their position
> ---------------------------------------------
> 
[...]
> 
> Proposal
> ========
> 
> Our proposal to address these problems is to add a new field that
> contains the USB Usage Page and Usage ID codes for keydown and keyup
> events.
> 
> In this proposal, the KeyboardEvent would be extended to include:
> 
>    interface KeyboardEvent : UIEvent
>    {
>       ...
>       readonly attribute unsigned long usbUsage;
>       ...
>    };
> 
> The usbUsage field is a combination of the USB Usage Page (upper
> 16-bits) and the USB Usage ID (lower 16-bits).  Some example usbUsage
> codes are given in Appendix B, but a complete list can be found in the
> USB HID Usage Tables documentation (see References).

I do not really like the idea of having the web platform being tied to
the USB specifications that way. I understand that the intent is to have
a code that can be used to identify a key and solve the two problems you
mentioned but if we had to use such code, I think it would be better to
use something else than USB usage.

USB usage isn't something we get for free in all major platforms. You
have to convert the platform's key representation to the USB usage
representation (AFAIUI, that's what the code you linked is doing [1]).
If we add to this the fact that USB isn't a technology that is used
everywhere keyboard inputs happens and might not last forever, by using
USB usage, we are just using an abstraction layer that is going to be
the USB representation of keys.

If we have to use such an abstraction layer between the underlying
platform identification for keys and the web platform, it would be
better to use a web-ier one. DE3 marked keyCode, charCode and which as
deprecated and using key and char that are returning strings instead.
Also, constant values are now preferred as strings instead of integers
in the Web Platform. It seems that USB usage as an abstraction layer
wouldn't work well there.

In addition, DE3 already has a string representation for a lot of keys
[2] which, I believe, is an abstraction layer on top of the platform
representation of keys. It doesn't give you the position of those keys
on the keyboard though.

I think we can easily solve Problem 1 by adding a new attribute in the
KeyboardEvent that would return the current 'code' of the key without
any modifier applied to it.

If we take back an example from the specs, currently we have:
  keydown: 'Shift', shiftKey
  keydown: 'Q', shiftKey
  keyup: 'Shift'
  keyup: 'q'

If we add that attribute that we could name |unmodifiedCode| or
|codeWithoutModifiers| or whatever is clear, we would have something like:
  keydown: 'Shift', shiftKey, 'Shift'
  keydown: 'Q', shiftKey, 'q'
  keyup: 'Shift', 'Shift'
  keyup: 'q', 'q'

That way, the developer would know that the 'q' key has been pressed and
released and we stay consistent with the D3E specifications.
I think that should solve Problem 1.

Regarding position of the key in the keyboard, I think the best solution
would be to use the 'locale' attribute from KeyboardEvent. That gives
enough information to the consumers of this API to know what would be
the key in a different keyboard layout.

The only additional information would be to know the difference between
keyboard layouts. I think that is something that could live in a JS
library instead of the Web Platform. Maybe providing a method like
|DOMString convertToLayout(DOMString layout);| would be more precise if
the underlying platform exposes a similar API. However, if that is not
the case, it would be exactly the same as doing that in a library except
that we would force all new vendors to implement the same function.
FWIW, I think relying on JS libraries to implement such method  would
also help crowd-sourcing the work and get as much layout as possible
supported.

[1]
http://code.google.com/searchframe#OAMlx_jo-ck/src/ui/base/keycodes/usb_keycode_map.h
[2] http://www.w3.org/TR/DOM-Level-3-Events/#key-values-list

Thanks,
--
Mounir

Received on Wednesday, 10 October 2012 16:42:03 UTC