W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] DOM Keyboard Event Level 3 questions about proposal

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 24 Sep 2012 18:29:46 -0700
Message-ID: <CANMdWTu5tmEQcgYVVv5UMdfoZZGRitfNLjXC9E5AAAzoOMTp4Q@mail.gmail.com>
To: Егор Николаев <termi1uc1@gmail.com>
Cc: whatwg List <whatwg@whatwg.org>
The right mailing list for these questions is www-dom@w3.org.


On Sat, Sep 22, 2012 at 2:57 PM, Егор Николаев <termi1uc1@gmail.com> wrote:

> Hello.
>
> Right now I'm looking for a way to implement 'DOM keyboard  event level 3'
> into my current project and also I'm developing polyfill for this API (
> https://github.com/termi/DOM-Keyboard-Event-Level-3-polyfill). As a
> reference I've used this standard (
> http://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120614/) along with
> Opera
> 12.10 and IE9+ implementations.
>
> I've a few questions:
>
> 1) How can I determine key combination triggering if user's locale is other
> than US_en? Both 'char' and 'key' properties return the symbol, that's
> specific to current user's locale. For example how can we detect 'Ctrl+S'
> combination? With this code:
>
> if(event.key.toLowerCase() == 's' || event.key.toLowerCase() == 'ы' || ...
> [and so on for every locale that is supported by your web application.]
>
>
> 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>).
>
>
> 3) Why the 'key' property is case-sensitive if we already have 'char'
> property for input symbol detection.
>
>
>
> To summarize I'd like to say that the new API doesn't solve any of the
> problems but creating new ones. Especially after cross-locales 'keyCode'
> property has been declared outdated.
>
>
>
> 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"
>   , ...
> }
>
Received on Tuesday, 25 September 2012 01:33:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC