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

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.

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

-Hallvord

Received on Monday, 11 March 2013 19:27:43 UTC