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

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


That is a problem, but is it fixable? Could we spec out those corner cases (possibly in combination with the key location property) in a way that would work with existing content and "rescue" keyCode?


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



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



Something like event.keyPositionColumn and event.keyPositionRow might be interesting.


Are there existing examples of (OS / Native) APIs that gives an application an "overview" of available physical keys? Maybe we should be looking at existing stuff for ideas..


BTW one of the use cases that .key and .char was criticized for not fulfilling was to keep track of keys that are held down (because there's no guarantee that a keyup event will have same .key and .char as the corresponding keydown). But maybe we should also have a KeyboardEvent.currentlyPressedKeys() method returning an array of values?


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



The implementation will want to handle that to make as much as possible of legacy stuff working. Just like Opera on mobile always faked an Enter press with keyCode 13 if the phone had some sort of "select" key, implementors that work with on-screen keyboards will want to know what values to use, and our spec's role is to help them as much as possible. So if we say the third row's second key should report coordinates [2,3] or keyCode 65 or event.quertyKey 'a' depends on what we think is most back- and forwards compatible, and if we get the spec right they should just implement it and win fame and fortune and back/forwards compatibility with web applications :-).



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

Received on Tuesday, 14 May 2013 12:56:08 UTC