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

> Do other browser vendors have thoughts here?


Trying to sum up some internal Opera discussion - hope I'm not mispresenting it, this isn't some "official" position either:


We've been considering two models or concepts, some (internal JS authors) suggested that modifiers keys that have caused a transformation of the current character (as given by event.char) should not be included in the event object. In other words, the Q keypress in Shift-Q would have {char:'Q', shiftKey:false} because the char is already "transformed" by the shiftkey. I don't think this is backwards compatible with existing content though.


I think there largely was an agreement that event.key should try to identify the "key" without any modifications or transforms caused by other keys or states. (This implies Opera is wrong to set event.key to 'Q' rather than 'q' in the Shift-Q keypress - personally I'd prefer {char:'Q', key:'q', shiftKey:true}). A mapping to the actual, un-modified "key" doesn't necessarily come "for free" on all platforms but on those that require extra work we have to do this work anyway, to set event.keyCode to what web content expects.


For alphanumerical keys and named function keys, this seems pretty simple to implement, for punctuation and "OEM keys" it might be more hazy, but generally I believe we have to rely on what the OS says the key is. Opera already gets for example "?" on a Norwegian keyboad right - the question mark is the shiftet state of the + key in this keyboard layout, so we fire the keypress event with these details: { key:'Add', char:'?', shiftKey:true }.


(On the other hand, we don't currently obey this proposed model for dead keys - striking the dead key for "umlaut", then o gives me a ö character as expected, but the keypress is {key:'ö',char:'ö'} rather than {key:'o', char:'ö'}.).


I think the above is a reasonable interpretation of the spec's intentions (however I do also think the spec is too vague, if it was precise enough we would not be having this discussion).
-Hallvord


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

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Thursday, 25 October 2012 08:34:16 UTC