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

Thanks for your comments Mounir.

On 10 Oct 2012 17:41:34 +0100, Mounir Lamouri wrote:
> 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.

We opted for USB because it's the closest thing we have to a
neutral cross-platform scancode.

Having said that, I'm not against using a different encoding that would act
as a universal scancode encoding, but it would look mostly like USB. If we
go this route, then the USB codes (or code names) would simply be the
starting point.

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

Including a field with the unmodified key would be an improvement, but note
that if the user changes the keyboard layout they will mess up any key
events that are "in flight". Another problem is that layouts can possibly
map multiple keys to the same character code, and we know that some
keyboard/layout combinations have multiple keys with *no* corresponding
character (e.g.: Japanese keyboard, US layout on Windows - the henkan, kana
and yen keys all return keycode=255).

This is one of the reasons why it's important to have a code that
corresponds to the key before *any* translation has occurred. Before the
modifier keys, before the keyboard locale mapping and before any
user-defined re-mappings have taken place.  That's the only way to reliably
identify a key given the myriad system/keyboard/locale configurations.

> 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]).

True, it's not free. But given a native scancode, it's a simple 1:1 mapping
for each platform. This is much cheaper and more reliable than trying to
re-constitute the original keycode after it's been through a few layers of
translation (os + keyboard locale + user-defined overrides).

Also note that the unmodified key is not something we get for free and it
can be non-trivial to calculate (unless it's provided by the native
platform). We would have to take into account the current locale/layout to
correctly determine the unmodified key. And if the OS maintains any
internal state (e.g., for dead keys), we would need to write code to undo
the effects.

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

That's a lot of additional information needed (dozens of layout tables for
each platform) that would take a lot of work to get correct. And even in
the best case it would still be unreliable because the mappings are not
always 1:1.

Our proposal avoids this because we explicitly define a 1:1 mapping between
the (unmodified) native scancode and the USB code. In addition to being
more reliable, having a single table is also much simpler to implement.

Thanks!
-Gary