- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: Mon, 11 Mar 2013 11:18:10 +0900
- 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 http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0160.html > 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 value. -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Monday, 11 March 2013 02:18:45 UTC