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

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

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

Summary: Needs some guidelines for computing key and char values of KeyboardEvent when...

Status:	RESOLVED FIXED

Alias:	None

Product:	WebAppsWG
Classification:	Unclassified
Component:	HISTORICAL - DOM3 Events (show other bugs)
Version:	unspecified
Hardware:	All All

Importance:	P2 normal
Target Milestone:	---
Assignee:	Travis Leithead [MSFT]
QA Contact:	public-webapps-bugzilla

URL:
Whiteboard:
Keywords:	needsReview

Depends on:
Blocks:

Reported:	2012-07-20 05:40 UTC by Masayuki Nakano
Modified:	2013-08-25 17:40 UTC (History)
CC List:	5 users (show)

See Also:

Attachments

Description Masayuki Nakano 2012-07-20 05:40:12 UTC

I think that D3E spec should provide some guidelines for computing key and char values of printable keys with some modifier keys.

For example, in most keyboard layout on Win/Mac/Linux, printable keys with Ctrl key doesn't cause text input. Only in this case, there is an example in current spec:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-Modifiers

This example describes the case for Latin keyboard layouts. Ctrl+'V' causes 'v' for both key and char attributes.

However, how about the cases: if the keyboard layout is not Latin inputable layout such as Arabic or Cyrillic?

I think that if Web applications want to handle such key events as a shortcut key on the page, they may want to know a Latin character of the key. Otherwise, they may want to know an unmodified character of the key.

I have some ideas. Fortunately, there are two attributes, key and char.

If the char value is same as unmodified (except shift) char, one of the attributes can be unmodified (except shift) character, the other can be Latin inputtable keyboard layout's character of the key. I think the former should be char, the latter should be key.

If the Latin character of the key isn't computable (e.g., OS's limitation) or the computed character is neither alphabet nor numeric, use same value of char. (If we would use this rules for other symbolic characters like punctuations, two or more keys might indicate same key attribute values, it's not good case for me)

Comment 1 Travis Leithead [MSFT] 2012-08-03 18:58:08 UTC

I took a look at: http://en.wikipedia.org/wiki/Keyboard_layout#Arabic
to get a feel for other keyboard layouts. Before taking action on this bug, I'd love to understand what the scenario is (or at least clarify it). You said:

(In reply to comment #0)
> I think that if Web applications want to handle such key events as a shortcut
> key on the page, they may want to know a Latin character of the key. Otherwise,
> they may want to know an unmodified character of the key.

So the scenarios sound like:
1. Shortcut keys (e.g., Ctrl+'ر' (U+0631: Arabic Letter Reh, which is in the same physical location on the Arabic keyboard as the 'V' key.)
2. Language-agnostic physical key location.

In #1 the scenario is language-dependent. The web author would need to assume that the user has an Arabic keyboard layout (much like EN web apps assume a Latin keyboard layout), and would code to the KeyboardEvent.key (or char) which would be a 'ر', when that key is struck.

In #2 the scenario is language-independent. The user wants to react to the physical key that has a label 'V' in latin-based keyboards, and 'ر' in Arabic keyboards, etc. In this case, the dev won't want to use key or char. Rather, the dev will want to use the scan code representation of the key, which is reported by legacy keyCode/charCode properties on the event.

Can you clarify your scenario (or confirm one of the above scenarios I called out) and then perhaps we can work out some clarifying examples for these if not already clear in the spec. 

Thanks!

Comment 2 Masayuki Nakano 2012-08-13 06:24:02 UTC

(In reply to comment #1)
> 1. Shortcut keys (e.g., Ctrl+'ر' (U+0631: Arabic Letter Reh, which is in the
> same physical location on the Arabic keyboard as the 'V' key.)
> 2. Language-agnostic physical key location.
> 
> In #1 the scenario is language-dependent. The web author would need to assume
> that the user has an Arabic keyboard layout (much like EN web apps assume a
> Latin keyboard layout), and would code to the KeyboardEvent.key (or char) which
> would be a 'ر', when that key is struck.
> 
> In #2 the scenario is language-independent. The user wants to react to the
> physical key that has a label 'V' in latin-based keyboards, and 'ر' in Arabic
> keyboards, etc. In this case, the dev won't want to use key or char. Rather,
> the dev will want to use the scan code representation of the key, which is
> reported by legacy keyCode/charCode properties on the event.

I think that the both scenario could be expected by web application developers. If somebody think that they want to know the input character if neither Ctrl key nor Meta (Command) key is pressed, they want the language dependent behavior.

On the other hand, If others think that they want to implement shortcut key on their web applications, they want to know which Latin character is expected by the user with the key combination.

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.

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.)

Comment 3 Travis Leithead [MSFT] 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

Comment 4 Masayuki Nakano 2012-09-12 03:43:30 UTC

Sorry, I missed to catch your replay due to during my vacation.

(In reply to comment #3)
> (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?

Yes.

> Numbers were tried in the past, but that didn't
> work out very well (charCode/ keyCode)

Yeah, but now, Firefox (starting 15) computes keyCode with ASCII capable keyboard layout information, so, it's possible on some desktop OS, though it's impossible on some other platforms like mobile OS such as Android.
 
> 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").

So, do you think that a key event caused by Ctrl+'ر' on Arabic keyboard layout should provide 'ر' with both .key and .char?

The most important point of this bug report is, there is not example for such cases in the spec. There is only Ctrl+v case in the spec. So, I don't agree with WONTFIX for this bug. My suggestion is just a "suggestion", not so important.

I hope D3E spec should provide examples for Ctrl+'ر' and Ctrl+Shift+'ر' (Shift+'ر' is '{') at least. What should be set to .key and .char in such cases.

And there is another issue. On Persian keyboard layout on Windows, Ctrl+Shift+'2' *inputs* ZWNJ.
https://bugzilla.mozilla.org/show_bug.cgi?id=414130

This means that web applications cannot detect whether a key event would cause text input actually by .char, .key or .getModifierState(). Is that known issue in the WG?

Yes, this is really another issue. However, if we don't have much time, now is the last chance to change the .key and .char definition again. If the key event doesn't cause text input actually like Ctrl+'v', it might be better .char to be empty string but .key to be 'v'.

> > 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

Yes. Therefore, I was thinking that it's better if .key or .char could provide the char value of ASCII capable keyboard layout on the environment.

I feel that if web app developers want to implement their own keyboard shortcut system, they need to refer the legacy keyCode or charCode with your idea. Therefore, I don't think that D3E spec doesn't recommend it by the warning strongly.

Comment 5 Travis Leithead [MSFT] 2012-09-12 18:29:26 UTC

Do you have an opinion on the proposal by Gary for usb scancodes?

http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html

It seems to address this issue.

Comment 6 Masayuki Nakano 2012-09-13 06:00:13 UTC

(In reply to comment #5)
> Do you have an opinion on the proposal by Gary for usb scancodes?
> 
> http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html

Ah, no. It's really different issue. I worry about implementing shortcut keys on web application. The scancode doesn't help it because the alternative key meaning cannot be resolved from physical keycode. For example, whether Ctrl+'ر' is same as Ctrl+'v' or not when the user activates ASCII capable keyboard layout.

Okay, I reopen this bug for requesting to add some examples for non-ASCII capable keyboard layout.

So, I want you to add following examples to the D3E spec:

* What are the .key and .char values of Ctrl+'ر' with Arabic keyboard layout
* What are the .key and .char values of Ctrl+Shift+'ر' with Arabic keyboard layout

Comment 7 Masayuki Nakano 2012-09-13 06:12:50 UTC

I filed bug 18867 for the additional suggestion in comment 4.

Comment 8 Gary Kacmarcik 2013-08-25 17:40:04 UTC

Fixed in latest ED