- From: Егор Николаев <termi1uc1@gmail.com>
- Date: Thu, 27 Sep 2012 21:47:20 +0400
- To: "Hallvord R. M. Steen" <hallvord@opera.com>, www-dom@w3.org
- Message-ID: <CAP=KyTi70GvpG444kjQBZw+nE87hmR_NQ-0=TszPwNis1xzUmg@mail.gmail.com>
> > > 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