25338 2014-04-14 09:19:42 +0000 D3E spec should recommend that KeyboardEvent.code of some keys whose label are different from PC's keyboard should be mapped from the key labels on Mac keyboard 2014-05-13 00:28:14 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified Macintosh MacOS X RESOLVED FIXED P2 normal --- 1 masayuki garykac garykac mike www-dom public-webapps-bugzilla oldest_to_newest 103805 0 masayuki 2014-04-14 09:19:42 +0000 On Mac, when PC keyboard is corrected, following keys have different label. Mac PC F13 PrintScreen F14 ScrollLock F15 Pause Help Insert *1 Clear NumLock *1 not present on modern Mac keyboard, but there was the key on legacy Mac keyboard, and Sun keyboard's Help key maps kVK_Help I think that we can ignore "backspace" vs. "delete" because Mac's keyboard also has "delete" key on function block with forward delete key's symbol. I.e., the delete key above return key works really as "Backspace" key. So, the problem is, if D3E spec undefined whether browsers should map code value from PC's key name or Mac's key name, there will be compatibility problem between browsers. I believe that browsers on Mac should prefer Mac's keyboard label. The reason is, these keys mentioned above are not work as PC. So, for browser users, they are different keys from PC. Additionally, ordinal Mac users must use Mac's keyboard rather than PC's keyboard. Therefore, I believe that D3E spec should note this, and browsers should map the keys as: Mac Preferred .code value F13 F13 F14 F14 F15 F15 Help Help Clear Clear 103806 1 masayuki 2014-04-14 09:22:13 +0000 FYI: Of course, KeyboardEvent.key value should be mapped from actual key's purpose since .key should represent its purpose. 103907 2 garykac 2014-04-15 21:15:50 +0000 This is already working as intended. There are different USB codes for F13-F24 = 68/69/6a and PrintScreen/ScrollLock/Pause = 46/47/48 So they are different keys. Apparently, the OS (or KVM switch) will map these keys to F13-15 on a Mac, but as far as the spec is concerned, we don't care. If these keys are reported to the browser as PrintScreen/et al., then they should be encoded as PrintScreen,... If they come through as F13... then that's how they should be encoded. In this case, Mac users will see F13,... because the OS (or some other lower component) is translating the PrintScreen into F13. So this is way beyond the scope of what we need to worry about for this spec. 103932 3 masayuki 2014-04-16 01:24:22 +0000 Indeed... On Mac, browsers cannot refer scan code because NSEvent of Cocoa and EventRef of Carbon don't provide it. Instead of that, virtual keycode provided by [NSEvent keyCode] is the only hint. So, we cannot distinguish F13-F15 and Help. So, using these values to .code must be the best solution. How about "Clear" case? It uses NumLock ID, IIRC. Should browsers use "NumLock" for "Clear" on Mac? 104312 4 masayuki 2014-04-24 03:59:58 +0000 Garykac: Could you check the my last question? I confirmed that Mac's clear key is NumLock key. Only the physical label is different. So, on Mac, which is better "NumpadClear" vs. "NumLock" on Mac browsers? 104314 5 masayuki 2014-04-24 04:18:45 +0000 According to the purpose of KeyboardEvent.code, even on Mac, the clear key should be "NumLock". However, I'm not sure if web applications want such behavior. KeyboardEvent.key of the key on Mac is "Clear". So, even if KeyboardEvent.code is "NumLock" on Mac, it might be OK for web apps. With those reasons, it might be better to use "NumLock" code value for the key even on Mac. But then, I strongly hope that the table in "6.3.1.4 Numpad Section" should add comment "Clear key on Mac keyboard" into "Notes (Informative)" cell for "NumLock". 104521 6 garykac 2014-04-28 04:06:27 +0000 If "Clear" on the Mac produces the same code as "NumLock", then it would be nice if they were the same. My only concern is that NumLock implies a state (locked or unlocked) which Clear doesn't have. Because of this, I think that it's better to have the Mac "Clear" key produce a separate code like "NumpadClear". 104768 7 garykac 2014-04-30 00:22:52 +0000 I'm OK with Mac Clear being the same as NumLock (esp since that's the USB code that it returns). We still need to keep NumpadClear around for keypad like the following (that Travis found): http://www.bing.com/images/search?q=microsoft+sculpt+number+pad&FORM=HDRSC2&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=22#view=detail&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=0 105796 8 garykac 2014-05-13 00:28:14 +0000 The Clear/NumLock issue is fixed in https://dvcs.w3.org/hg/dom3events/rev/6c2226898bf9