[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

--- Comment #4 from Masayuki Nakano <masayuki@d-toybox.com> 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.

-- 
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 Wednesday, 12 September 2012 03:43:32 UTC