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

Sorry for the long delay to replay.

On 2013/03/02 8:32, Gary Kacmarcik (Кошмарчик) wrote:
> On Wed, Feb 27, 2013 at 7:10 PM, Masayuki Nakano <masayuki@d-toybox.com
> <mailto:masayuki@d-toybox.com>> wrote:
>
>     Hello.
>
>     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 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. 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.
>
>
> I agree that it could just as easily be a numeric value. We originally
> proposed this, but received comments that a descriptive string is more
> in desirable in W3C specifications.
>
> For context, see Mounir's "web-ier" comments in
> http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html and my
> response to Florian in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0176.html
>
> With regards to the naming, note that this is pretty much what the USB
> spec does - they needed a name for each key and they standardized on the
> en-US names for the keys. A key difference is that the USB name was just
> for descriptive purposes (since the actual codes were numeric) whereas
> we're using the name as the code.

I don't like W3C specs reference device dependent spec such as USB spec. 
According to the purpose of .code and if its type should be DOMString, 
then, I like more physical key name. E.g., AlphanumericKey1-1 (Row - 
Col). ANSI keyboard layout based names are pretty logical only with ANSI 
keyboard layout.

>     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.
>
>
> Based on
> http://unicode-inc.blogspot.com/2012/06/cldr-2102-new-t-extensions-for.html,
> I would expect the dvorak layout to have a BCP-47 value of "en-t-k0-dvorak".

Hmm, I still think that it's not good idea to make IDs for any keyboard 
layout, especially, dynamically. I believe that it's not possible idea 
to implement all platforms.

Please not that user may use customized keyboard layout. What's a good 
name for it??

>     3. KeyboardEvent.queryKeyCap() takes any KeyboardEvent.code value.
>     So, this method works like static class method of C++, not an
>     instance's method.
>
>
> Yes, we discussed the best location for this API, and a static method
> was suggested as the best approach since a primary use-case is in a
> preference dialog where there is no KeyboardEvent instance.
>
> See Hallvord's comments in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0183.html
>
> i wish that IDL had a way to mark static methods, but I didn't see a way
> to do that.

Yeah, static like methods are not available. However, more general 
object should have the API. I agree with the Hallvord's idea. I.e., 
window.KeyboardLayout having it is better than current spec. I think 
that resolving key-char mapping of non-current key event's key is out of 
scope of D3E nor D4E.

>     I think that this is overspec for web developers. I don't think such
>     high level API is required. I think that the spec should remove
>     KeyboardEvent.code attribute.
>
>
> Such an API is the only way to get the information needed for a webapp
> to display the character associated with a particular key. Florian
> discusses some of the motivation for this in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0170.html and
> describes why 'code' is needed to store these preferences in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0174.html
>
> As for KeyboardEvent.code, it has a number of documented uses and is
> fairly trivial to implement (lookup table from local scancode to "web"
> code).

Understood the purpose, thank you.

>     And KeyboardEvent.queryKeyCap() works with the key of the cause of
>     the event.
>
>
> The 'key' value is too ambiguous to use as an identifier for a physical
> key. For example, on a French keyboard a 'key' value of '2' can be
> generated by the numpad '2' key or by Shift-'é'.  The keycap value
> returned should be '2' and 'é', respectively.

Yes, but for non-gaming shortcut key implementation, typically, the 
meaning of a key is more important than physical key position. For 
example, typically, Ctrl+F is a shortcut key for "Find". The "F" comes 
from the initial of "Find". This is easier to remember the relation 
between a command and a shortcut key.

My idea is, developers should use .key and/or 
KeyboardEvent.queryKeyCap() for implementing normal shortcut key.

On the other hand, developers who need the physical key location, e.g., 
game developers, should use window.KeyboardLayout or something.

So, I'd like to suggest that the API set for resolving physical key 
location should be spun out from KeyboardEvent, e.g., window.KeyboardLayout.

>     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.
>
>
> Making queryXxx an instance method ignores the use case where people
> need to get the char associated with a key when they don't have a
> KeyboardEvent instance (for example, when showing a preferences dialog
> that allows a user to set their key mappings for a game).
>
> The whole point of the 'code' attribute is to make the "raw key
> information" available *externally* in cross-platform way. There are
> use-cases (most notably, games) that need this information since 'char'
> and 'key' are inadequate.

As I said above, I believe that the purpose you mentioned should not be 
resolved with KeyboardEvent methods.

>     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
>     <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341> and
>     https://www.w3.org/Bugs/__Public/show_bug.cgi?id=18867
>     <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18867> will be fixed
>     simply.
>
>
> If I understand it correctly, 18867 is about making char = '' (empty)
> for non-printable characters (like when ctrl is held).  I don't think
> that's related to this topic, but FWIW it sounds like a reasonable idea
> to me.

The reason why I picked up the .char and .key behavior is, these 
behavior is important for deciding what function should be defined in D4E.

-- 
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Tuesday, 7 May 2013 10:23:06 UTC