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

On 2013/03/12 4:27, Hallvord R. M. Steen 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"?

As I mentioned in 
<http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0085.html>, I 
think that the .code values should be renamed with physical key 
position. Such as Alphanumeric1-1 (row-col). I understand that the 
motivation for implementing the .code is that web developers want to 
know the physical key position and its label (.queryKeyCap()). If so, 
the logical key name of ANSI keyboard layout doesn't make sense for the 
result of .code attribute.

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

One .keyCode value isn't mapped as only one physical key. However, 
indeed, if .code value were opaque number value, similar confusion of 
.keyCode would be back. It's really bad scenario, we shouldn't do that, 
perhaps.

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

Understood. I believe that we shouldn't solve this request with 
KeyboardEvent's method. See 
<http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0085.html> for 
my idea. There should be separated API set for solving the caption of 
the key from .code value.

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

Yeah, I understood that.

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

Hmm, .code must not be available with virtual keyboard on mobile device 
because virtual keyboard doesn't need to be same layout of PC keyboard. 
According to this angle, web applications which only test with .code 
value is inaccessible from mobile devices. If browsers set .code value 
for input from virtual keyboard which isn't similar to PC keyboard 
layout, then, it doesn't make sense for the purpose of the .code and 
.queryKeyCap(). .code doesn't represent the "physical" key position.

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

I think that if IE team cannot change the name by some their business 
reasons, we should give new names for them. Implementing new attribute 
without CR spec is bad thing if the implementer don't want to change the 
behavior for newer behavior which is discussed in W3C.

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

Received on Tuesday, 7 May 2013 10:51:25 UTC