Re: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

Hi Masayuki-san, 
good points - I agree with some of them, not others. One general point: I think we're trying to make life easier for JS developers with this API - they won't necessarily be easy to implement, but if they simplify authoring it's still IMO worth it.


Further comments below..


> 1. KeyboardEvent.code value is named from the unshifted character of 
> en-US keyboard layout. However, this is not useful information for other 

> locale developers.


I believe that the information that *is* useful for those developers is already available in the other properties, no? If .code is meant for developers who want to write cross-locale applications and only need to take physical key positioning into account, it makes sense to me to use a standard en-US layout as a reference simply because it's a well known keyboard layout that most developers either will be familiar with already or easily find descriptions of.


> I think that the purpose of this value is, making 
> identified value for each physical key. If so, it's not problem even if 

> it's a just opaque number value.


True, but this is probably harder for authors to understand.


> For example, it's easier to implement 
> that UA sets scan code value on Windows, hardware_keycode value on GTK, 
> native virtual keycode value on Mac.



..but would those values always match cross-platform for a given key? We certainly *don't* want to make JS authors write platform-specific code..
 
> 2. KeyboardEvent.queryKeyCap() works with local identifier. However, it 
> doesn't make sense. For example, we can say both locales of Standard US 
> keyboard layout and Dvorak keyboard layout are "en-US". Similarly, some 
> other locales have two or more keyboard layouts. So, using locale 
> identifier for specifying keyboard layout is really wrong idea.



This is a good point, we may need to specify names like 'en-us-standard' or 'en-us-dvorak'.
 
> 3. KeyboardEvent.queryKeyCap() takes any KeyboardEvent.code value. So, 
> this method works like static class method of C++, not an instance's 
> method. I think that this is overspec for web developers. I don't think 

> such high level API is required. 


The use case for this was displaying information to the user, for example telling the user what keys should be pressed for various actions. Hence it is necessary to be able to call this method even outside of event handlers, and it's spec'ed as a "static class method" for that reason.


> I think that the spec should remove 
> KeyboardEvent.code attribute. And KeyboardEvent.queryKeyCap() works with 
> the key of the cause of the event. Then, UA can store raw (system 
> native) identifier of the key internally. This make implementations simpler.



Doesn't help the above use case, unfortunately.


> 5. I'd like to suggest KeyboardEvent.queryChar() instead of 
> KeyboardEvent.code and KeyboardEvent.queryKeyCap(). 
> KeyboardEvent.queryChar() has two arguments, one is modifier key state 
> (space separated modifier key list, if there is unknown modifier key, it 
> should raise an exception). The other is a bool value whether it 
> specifies current keyboard layout or current ASCII capable keyboard 
> layout. This method should work only with trusted key event because 
> untrusted key event cannot have raw key information internally. If the 
> user is using ASCII capable keyboard layout such as Japanese keyboard 
> layout, then, the bool argument makes no difference for the result.
> 
> Then, If KeyboardEvent.char is same as (a) and KeyboardEvent.key is same 
> as (b) without any modifier key, then, 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341 and 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18867 will be fixed simply.



I personally agree that it would be nicer to fix KeyboardEvent.char and KeyboardEvent.key than adding yet-another-property with KeyboardEvent.code. I guess IE10 implemented .char and .key as spec'ed already though - we could probably ignore the Opera Presto implementation as it's being discontinued and few developers targeted their content at Opera, but if IE already shipped something it's a lot harder to re-architect it :-(

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

Received on Thursday, 28 February 2013 08:15:59 UTC