This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Mac, Command key (meta key) is general modifier key of shortcut key. Therefore, internally, Mac switches the printable key's layout as ASCII capable when Command key is pressed. In this case (i.e., while Command key is pressed), KeyboardEvent.key value should be the ASCII character? Or since it's not inputting text, it should be unmodified character (except Shift)? If the former, the behavior is consistent with Control key pressed case. If the latter, it might be better for users especially for Dvorak-QWERTY layout users. (Dvorak-QWERTY layout switches the printable keyboard layout from Dvorak to QWERTY at pressing Command key)
<masayuki> shortcut keys of apps for English language users are designed for QWERTY. Therefore, Dvorak layout isn't useful for shortcut keys. [17:54] <garykac> Is that just a weird behavior of Dvorak to deal with the fact that the keycaps don't match the layout. [17:54] <masayuki> Some Mac's Dvorak users like this special layout. [17:55] <garykac> If the OS/keyboard-layout went through the trouble to do this, then it's probably nice to support it. [17:55] <masayuki> Non-ASCII keyboard layout such as Arabic keyboard layout also has same issue. [17:56] <garykac> So an Arabic keyboard generates QWERTY values when the command key is pressed? [17:56] <masayuki> Pressing command key swtches the printable keyboard layout to QWERTY. [17:56] <garykac> I've never tried that... [17:56] <masayuki> garykac: yes. You can confirm it with keyboard viewer of Mac OS X. [17:56] <garykac> en-US? (not en-UK or anywhere else) [17:57] <masayuki> I think it's en-US. [17:57] <masayuki> IIRC, though. [17:58] <garykac> According to Keyboard viewer... [17:58] <garykac> cmd-a produces 'a' [17:58] <garykac> cmd-shift-a produces 'a' (also lowercase) [17:58] <garykac> for en-US [17:58] <garykac> For Arabic [17:59] <garykac> cmd-ش produces 'a' [17:59] <garykac> cmd-shift-ش produces 'A' (uppercase) [17:59] <garykac> This makes me sad [17:59] <masayuki> Oh... [18:01] <garykac> My preference is for whatever the OS gives us easily. [18:01] <garykac> I presume that the OS is doing things for a good reason. [18:01] <garykac> And I'm not sure how to map this equivalent into Windows or Linux. [18:02] <masayuki> garykac: I don't think that Windows and Linux need to do same behavior since Command key is a special modifier of Mac OS.
I'd like to suggest that D3E spec should define the .key value of printable keys as following: * When a printable key inputs text, the value is the input text. (Including shift key or AltGr key press) * When a printable key doesn't input text but native key event introduces different printable text, the value should be the printable text. (command key case of Mac) * When a printable key doesn't input text and native key event doesn't introduce printable text (e.g., introduces control character), the value should be the text without the modifier key (e.g., control key is pressed on all platforms or alt key or win key is pressed on Win/Linux). If AltGr causes not inputting text, the key value should be computed without AltGr, I think.
FYI: Gecko will implement .key for printable keys (except dead keys) this week. As I tested on Mac with current patch, ctrl+shift+a represents 'A' on Mavericks. Although the key is represented as 'a' on keyboard viewer. https://bugzilla.mozilla.org/show_bug.cgi?id=912858
In looking at this on Windows, Ctrl+A (when using an Arabic keyboard layout) has the same behavior (a key value of 'a' is sent with the Ctrl modifier active, otherwise the key code 'KeyA' generates the Arabic character. >>In this case (i.e., while Command key is pressed), KeyboardEvent.key value >>should be the ASCII character? Or since it's not inputting text, it should be >>unmodified character (except Shift)? >> >>If the former, the behavior is consistent with Control key pressed case. I think it is the former. What layout _is_ being used when the modifier key (Ctrl/Command) is active? Masayuki reports an "ASCII capable" layout--wondering how to spec this?
The current spec says simply "default keyboard layout" because we can't be more specific than that at the moment. To specify it in more detail, we'd need to know what happens when: French default OS, Arabic keyboard layout, press Ctrl-q (=KeyA, next to CapsLock). Do we see 'a' or 'q'.