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

On 11 March 2013 12:27, Hallvord R. M. Steen <hallvord@opera.com> wrote:

> Siterer Masayuki Nakano <masayuki@d-toybox.com>:
>
>  On 2013/02/28 17:15, Hallvord Reiar Michaelsen Steen wrote:
>>
>>> 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.
>>>
>>
>> My concern is, the code values don't indicate that they are named for
>> en-US (QWERTY) keyboard layout.
>>
>
> Would it help to name them "event.enUSKeyboardCode"? Or "event.quertyCode"?
>
>
>  Therefore, I believe that a lot of web
>> developers will misunderstand the meaning of code value.
>>
>
> We're trying to fulfill somewhat contradictory use cases, in an area of
> great complexity. I think some confusion is inevitable - though having said
> that I agree that if we can find a path that causes as little confusion as
> possible that's obviously a good thing ;), so I don't intend to just brush
> your concerns and opinions away..
>
>
>  For example, when Japanese web developers try to handle Ctrl+':', they
>> might (want to) compare with 'Colon' rather than 'Quote'. It feels very
>> strange for me. Indeed, as you say, .key value should be ':'. However,
>> at least in Japan, it's not intuitive behavior because most Japanese
>> people don't familiar with en-US keyboard layout (especially, which
>> punctuation key inputs which character). So, I don't feel en-US QWERTY
>> layout is well known layout for the people all over the world.
>>
>
> That's probably true. However, ANY attempt at aligning .code with the key
> "caption" of the locale/layout will break what we're trying to make
> possible - namely a static reference that will make an app using it work
> across locales.
>
> The queryKeyCap() method, for example, can't solve this use case. As far
> as I can tell from the proposals, if you try to write code using
> queryKeyCap() to work on both Japanese and en-US systems you'd end up
> writing
>
> if ( event.queryKeyCap() == ':' || event.queryKeyCap() == '"' )
>
> - which means we'd be throwing developers right into the complexity we're
> trying to handle for them.
>
>
>  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.
>>>
>>
>> Yeah, I realized that if we use unique numbers like keyCode, most web
>> developers will probably compare the code value with fixed number.
>>
>
> If we go the "opaque number value" route, we're basically re-inventing
> event.keyCode, and should IMO write a real, normative spec for
> event.keyCode rather than adding something that's almost exactly the same.


The critical difference between "keyCode" and "code" is that the prevalent
implementation of "keyCode" uses Windows virtual-key codes, which change
for some keys depending upon layout. It's also implemented using other
completely different schemes by some browsers. So normative documentation
isn't really an option.

This is one reason why the original "code" proposal used numeric codes
based on the USB Keyboard Usage tables.

 Then, such developer's web application won't work for unexpected
>> keyboard layout.
>>
>
> ..we'd have to spec it in a way that would overcome that problem ;-) i.e.
> make sure that event.keyCode to the best of our ability would return the
> same value for "same" keys across layouts.
>
>
>  In Japan, most people don't familiar with en-US
>> keyboard layout, however, actually, few people prefer en-US keyboard
>> layout rather than JIS keyboard layout. So, it's possible to cause such
>> inaccessible web application. However, I don't like the value name is
>> based on en-US QWERTY layout... Hmm...
>>
>
> The familiarity argument is important, but perhaps simply naming it
> event.quertyCaption or event.quertyValue would be sufficient?
>
>
>  ..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..
>>>
>>
>> Yeah, I agree with that. My main idea is, the .code value should not be
>> referred by web developers directly. In the current draft, they should
>> always use queryKeyCap().
>>
>
> ..now we risk going back to assuming that our "target developer" cares
> what the key's "caption" is in the first place..
>
>
>  A. Needs an API for letting developers know the input character of the
>> fired keyboard event with other modifier state or layout.
>> B. Needs an API for letting developers know the input character of
>> specified keyboard event.
>>
>> So, aren't these API better and enough for developers?
>>
>
> Because developers are asking us for
>
> C. Need an API to let my app detect a keydown on the 3rd row, 5th key of
> the keyboard - regardless of what's written on it or what character or
> action it generates - in a way that works across keyboard layouts.
>
> (Snipping some of your reply.)
>
>
>  Then, the code *attribute* doesn't necessary. Only the code values are
>> necessary. Then, we can avoid the issue that web developers will
>> compare .code value directly.
>>
>
> We're not aiming to "avoid" this issue, we're aiming to embrace it because
> it seems a useful way to meet some use cases.
>
> Now, this is obviously an area that is also made complex because ideally a
> script should also work across platforms - with phone keypads, tablet
> on-screen IME solutions etc. The platform does have one declarative way to
> define shortcuts (HTML accesskey attribute) which leaves the UA more room
> to do cross-platform tricks because of its declarative nature. IMO we
> should promote accesskey for this reason, and make sure the implementations
> are good, while recognising that accesskey doesn't solve all use cases and
> thus move forward with the ideas we're discussing here.
>
>
>  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 :-(
>>>
>>
>> I think that IE can change the behavior. The .key and .char have only
>> been implemented on IE. So, such state attribute isn't useful for most
>> web developers. And also, even if the change will cause something
>> trouble on a few web applications, such developers should change the
>> code for the latest spec. D3E is still "Working Draft".
>>
>
> Maybe, maybe not - we'd have to ask the IE team and try to survey if sites
> and apps have started using .key and .char.


"key" and "char" fulfill different requirements to "code".  In principle
the "key" attribute as currently defined in the D3E spec makes sense and is
useful to applications.

As has been discussed elsewhere, "char" needs some further work, given that
it only makes sense for key events that generate printable character input,
and for Dead Keys and IMEs there is not necessarily a 1:1 correspondence
between key events and input characters.