W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2012

Re: DOM Keyboard Event Level 3 questions about proposal

From: Егор Николаев <termi1uc1@gmail.com>
Date: Thu, 27 Sep 2012 21:47:20 +0400
Message-ID: <CAP=KyTi70GvpG444kjQBZw+nE87hmR_NQ-0=TszPwNis1xzUmg@mail.gmail.com>
To: "Hallvord R. M. Steen" <hallvord@opera.com>, www-dom@w3.org
> 2) There's no clear statement about 'char' and 'key' values for special
>> symbol key press events. Opera 12.10 x64 Win7x64  (12.10.1592 at least),
>> for example, returns some gibberish in key and char property while Ctrl key
>> pressed. You can see it for yourself by going to
>> http://h123.ru/-/tests/KeyboardEvent/ with Opera 12.10 beta RC and
>> pressing Ctrl+Q (or Ctrl+<any character>).
> What Opera returns is the ASCII control character that key press would
> insert in a terminal window or something. It's implemented that way because
> the spec is somewhat unclear and there was no real discussion or consensus
> when I asked about this back in January.
> What does IE9 do, BTW?
> "ASCII control character" is useless for web developers :( We need full
accountability for keyboard events in web application

IE9 return empty value for 'key' and 'char' with Ctrl pressed, and null for
"char" and standard-compliance key value for 'key' with Alt pressed. So
there is no standard-compliance way to detect Ctrl+<any key> combination in
IE9. In the over hand detection Alt+<any key> is quite possible in IE9
unlike in Opera 12.10. In both browsers I can detect key combinations
through old good way via keyCode/charCode/which, but this negates the value
of the current standard.

> As a solution I'd like to suggest 'char' and 'key' logical division.
>> 'Char' property should return input symbol (just like it does right now)
>> and 'key' property should always, for any special symbol key pressed,
>> return lowercased US_en locale symbol for any symbol value. For example it
>> can be:
>> event :{
>>   key : "q"
>>   , char "Й"
>>   , shiftKey : true
>>   , locale : "RU_ru"
>>   , ...
>> }
>  Looks like a more author-friendly solution, though I don't know if it's
> possible to implement it. It presumably would take quite some work if we
> need some sort of conversion tables for all keyboard layouts to know what
> the corresponding US_en key is.. Or do we?

I can do it right now via JS:
String.fromCharCode(event.keyCode).toLowerCase(). For "keydown" and "keyup"
events event.keyCode "always" (for symbol keys) would be ASCII code of
en-US symbol in uppercase. Am I wrong? I tested it in IE6+, Chrome 12+,
Safari 5+ and Opera 10+. Based on that technique I can made polyfill for
IE9 and Opera 12.10.
Received on Thursday, 27 September 2012 17:47:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:19 UTC