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

Do other browser vendors have thoughts here? Related to this proposal, is
that I'd like to have some confidence that we're not going to be changing
the key/char properties on key events before WebKit moves forward
implementing them.


On Wed, Oct 10, 2012 at 9:41 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> 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
>
>