27990 2015-02-10 04:43:53 +0000 [D3E-key][D3E-code] "#" and "*" button of feature phones should be defined 2015-03-11 01:41:57 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified Other All RESOLVED FIXED P2 normal --- 27996 1 masayuki travil garykac jackalmage mike www-dom public-webapps-bugzilla oldest_to_newest 117780 0 masayuki 2015-02-10 04:43:53 +0000 Simple phones has "#" and "*" around "0" key. D3E (or UIEvents) should define these keys. 117781 1 masayuki 2015-02-10 04:51:42 +0000 I don't know if Android defines specific keycode values for them, though. 117782 2 masayuki 2015-02-10 04:54:15 +0000 https://source.android.com/devices/input/keyboard-devices.html#legacy-unsupported-keys http://developer.android.com/reference/android/view/KeyEvent.html 117825 3 jackalmage 2015-02-10 23:16:20 +0000 Should they just be the # and * characters? 117829 4 masayuki 2015-02-11 00:39:36 +0000 (In reply to Tab Atkins Jr. from comment #3) > Should they just be the # and * characters? Yeah, if they generate text in <input>, .key should be so. 117835 5 masayuki 2015-02-11 00:55:08 +0000 I guess that whether they causes inputting "#" or "*" depends on the design of the device. Some vendor may map them as printable keys, the others may map them as non-printable keys. For the latter case, these keys should have independent key names, I think. Similarly, their .code values are difficult issue. They may be shared with normal PC's scancode. Even in this case, browser vendors need the guideline of the key. If using Digit3 and Digit8 for them because of en-US keyboard layout, they may be conflict with "3" and "8" keys on the phone. So, for .code value, The spec should define both (1) recommended .code value if they are mapped to scancode shared with some keys on PC keyboard and (2) independent .code value if they are not mapped to scancode which is not used on PC keyboard. 117840 6 garykac 2015-02-11 01:41:53 +0000 For 'key': I can see this either generating '#' and '*', or being considered unprintable. We should match whatever the current common behavior is. For 'code': NumpadAsterisk and NumpadHash seem like the best choices since these are distinct keys. 'Digit3' and 'Digit8' are keys that vary based on the locale and just happen to map to '3' and '8' on US layouts. They are conpletely different keys on different layouts and have no relation to the phone pad '*' and '#' keys. Thus, these values are not appropriate for use here. 117844 7 masayuki 2015-02-11 02:00:36 +0000 (In reply to Gary Kacmarcik from comment #6) > For 'key': > I can see this either generating '#' and '*', or being considered > unprintable. We should match whatever the current common behavior is. Yeah, I'm asking the behavior to a vendor. However, I think that D3E key should define specific names for the keys because some vendors may make them non-printable keys. > For 'code': > NumpadAsterisk and NumpadHash seem like the best choices since these are > distinct keys. Agreed. > 'Digit3' and 'Digit8' are keys that vary based on the locale and just happen > to map to '3' and '8' on US layouts. They are conpletely different keys on > different layouts and have no relation to the phone pad '*' and '#' keys. > Thus, these values are not appropriate for use here. I agree with your idea about the locale issue. However, I still think that there should be some guide lines if some vendor cannot use independent scancode for them. In such case, web browsers cannot distinguish them as Numpad* if the platform doesn't have independent virtual keycode. 117955 8 masayuki 2015-02-16 10:28:01 +0000 FIY: These keys might be defined by ITU-1.161: http://en.wikipedia.org/wiki/Telephone_keypad http://en.wikipedia.org/wiki/E.161 118514 9 garykac 2015-03-11 01:41:57 +0000 USB also has them in Page 0x0B. 'Star' seems to be a more common name when used on a phone, so I'm going with NumpadStar and NumpadHash. Fixed in : https://dvcs.w3.org/hg/dom3events/rev/b1ba98eac6aa