W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: DOM Keyboard Event Level 3 questions about proposal

From: Masayuki Nakano <masayuki@d-toybox.com>
Date: Tue, 26 Feb 2013 15:17:58 +0900
Message-ID: <512C5396.5080006@d-toybox.com>
To: Егор Николаев <termi1uc1@gmail.com>, www-dom@w3.org
Sorry for the big delay for replay.

On 2013/02/05 15:19, Егор Николаев wrote:
> I wonder, why we need modified (upper cased) key value if we already
> have shiftKey=true.
> C { key: "c", char: "c" }
> C + Shift { key: "C", char: "C" }
> It will make JS-developing harder with no reason.
> Instead doing so:
> switch(event.key) {
>    "a":
>    "b"..
> }
> I will have to write  switch(event.key.toLowerCase()) . What point of it?

I think that non-alphabet keys such as numeric keys and other keys 
(e.g., [, : and / keys) should respect the Shift key state. And also, 
Hebrew keyboard layout, unshifted state inputs Hebrew characters but 
with shift key, inputs upper alphabet characters. So, I think that it 
does make sense the behavior.

> And I don't understand the idea of bringing the same value to key and
> char properties. What point of it either? With the different values of
> key and char properties it will bring more freedom to analyze keyboard
> input data.

Yeah, I agree with a part of your idea. If a printable key event doesn't 
cause text input, e.g., pressed with Control key, I strongly believe the 
char value must be empty string and key value should be the input 
character only with Shift key or AltGr key. Then, web application 
developers can handle the printable key with Alt, Control or Meta key 


Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
Received on Tuesday, 26 February 2013 06:18:22 UTC

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