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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341

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
(http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-getModifierState)
right?

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
here:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-getModifierState

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 23 August 2012 22:24:39 UTC