W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 24 Oct 2012 16:57:22 -0700
Message-ID: <CANMdWTv336a4hPeJWFCNEVy-XOd3+VWv5tUP3-gdLy_m0VtkwA@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: "www-dom@w3.org" <www-dom@w3.org>
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
Received on Wednesday, 24 October 2012 23:58:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 23:58:15 GMT