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: Mon, 11 Mar 2013 11:18:10 +0900
Message-ID: <513D3EE2.70503@d-toybox.com>
To: Егор Николаев <termi1uc1@gmail.com>, "www-dom@w3.org" <www-dom@w3.org>, Brad Pettit <Brad.Pettit@microsoft.com>
On 2013/03/08 5:24, Егор Николаев wrote:
> Masayuki Nakano
>  > 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.
> You not exactly understand me. Do we talking about the same? I suggest
> to unified "key" property, so in any keyboard layout "key" property
> should return exactly the same value, with shift key or without.

Looks like you already see the "code" attribute information. See also 

> And again, you have "char" property with actually entered value.
>  > If a printable key event doesn't cause text input
> What the difference causing text input or not? WYSIWYG developers has
> "char" property for detect entered character. Game and UI developers
> should have "key" value to detect shortcuts(including in WYSIWYG
> editors). "char" and "key" should not be the same. "key" value should be
> character values of a normal QUERTY (en-US) layout
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827 .

I don't understand why you think that en-US QUERTY keyboard layout is 
useful in any locale...

I think that .char should be useful value for implementing text editor 
implemented with <canvas> and DOM. For example, if Ctrl+C is pressed, 
then, if .char is empty value, it lets web developers know the key 
combination isn't inputting text. Otherwise, they cannot know the fact 
because even on Windows, some keyboard layout uses Ctrl key for 
inputting text.

> Again, the main reason why "key" should not be the same as "char" and
> "key" should not modified by shift key is to bring to web-developers the
> same mechanism as event.keyCode property.
> Today key detection is
> if(  event.keyCode  == 65 )
> Tomorrow it should be
> if(  event.key  == "a" )
> I, as web-developer, do not understand why it should be
> if( event.key.toLowerCase()  == "a" )  or worse if(  )

As I mentioned, non-alphabet input keys like punctuations or non-Latin 
keyboard layout, I believe it's not useful the value without Shift key 
state since it's impossible web developers cannot know the shifted key 

Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
Received on Monday, 11 March 2013 02:18:45 UTC

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