W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2012

[Bug 18341] Needs some guidelines for computing key and char values of KeyboardEvent when some modifier key is pressed and not causes text input

From: <bugzilla@jessica.w3.org>
Date: Thu, 23 Aug 2012 22:24:33 +0000
Message-Id: <E1T4fpJ-0003nR-BR@jessica.w3.org>
To: www-dom@w3.org

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
           Keywords|                            |needsReview
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-08-23 22:24:33 UTC ---
(In reply to comment #2)
> Therefore, I think that "char" should have language-dependent value and "key"
> should have language-independent value if the key combination doesn't cause
> text input.

So, we're talking only about keys that are being modified by a modifier key

As it is today, key is generally the language-independent value (when no text
input (i.e., characters) are produced by the key, and char is not available
_unless_ the key produced a character value.

In the cases I described previously, I'm not sure what language-independent
value I could return for key. Numbers were tried in the past, but that didn't
work out very well (charCode/ keyCode), and row/column info wouldn't work out
well because the OS software generally doesn't tell browsers that info (and it
would change depending on physical key layout). 

My examples using Ctrl+'ر' (U+0631: Arabic Letter Reh) and Ctrl+'v' also don't
reflect the conditions you stated above, because they _do_ produce a text input
character ('v' with most modifiers and 'V' with the shift modifier on en-US) in
addition to trigger OS-or-app specific commands (such as Paste).

In general, this is a problem that has been debated a lot. Scenarios the rely
on physical key placement are very error-prone, and can usually be adapted to
language-dependent keys via some simple UI model (e.g., "user, please press the
key you'd like to use for this shortcut").

> And I think that D3E shouldn't recommend to use legacy keyCode and charCode
> because the values haven't been standardized yet. However, if they would be
> standardized, it's too risky web browsers to change the values due to
> compatibility with old web applications which check different values for each
> UA. (And also, Firefox uses them in its UI code, so, changing keyCode and
> charCode needs big change and a lot of tests.)

You're correct, and D3E doesn't recommend using those keys--see the warning

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 23 August 2012 22:24:34 UTC

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