This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Table 6.2.7.1 - Key Values List http://www.w3.org/TR/DOM-Level-3-Events/#key-values-list There is both an "OS" key and a "Meta" key. These are the exact same key and should not have different codes. This key is for the Windows key, Apple's Command key and Sun's Meta key. We need to choose one name, "OS" or "Meta", and be consistent in the spec. I think "OS" is a better name, but "Meta" might be preferred for historical reasons. The following needs to be made consistent: 1) The "metaKey" attribute in KeyboardEvent (rename to "osKey") 2) The modifier list for getModifierState (in 5.2.5) shouldn't have both "Meta" and "OS". (Remove "Meta") Also this list of modifier keys should be put in a table rather than tucked away in this method description.
I don't think this is valid suggestion if Gecko's implementation is intentional behavior of original idea. Gecko maps: Windows Mac Linux "OS": Win logo key <no key> Super key and Hyper key "Meta": <no key> command key Meta key On Linux, Shift+Alt key typically causes GDK_Meta. Additionally, the physical win logo key causes GDK_Super or GDK_Hyper. So, on Linux, we need both key names of them.
As I understand it, the Win/Command/Meta were always intended to map to the same key, but the Windows browsers never implemented that part. This is consistent with the definitions in the USB* spec and it explains why the "Win" key is missing from the original spec (which would be a blatant omission). I think that "Super" and "Hyper" should really be encoded as separate keys - it seems wrong to map them to the same key value. Does the following make sense for you: Windows Mac Linux "Super": <no key> <no key> Super key "Hyper: <no key> <no key> Hyper key "Meta": Win logo key command key Meta key The only thing I don't really like about it is that pressing the logo key on Linux generates "Super" by default (rather than "Meta" like Mac/Win). * See the "GUI" key in: http://www.usb.org/developers/devclass_docs/Hut1_11.pdf Page 59, footnotes 10, 23 and 24.
If "Super" and "Hyper" should be used for physical windows logo key on Linux in most environment, it worsen the usefulness of .key for web developers. If they want to handle the physical Windows logo key with .key, then, they need to check "OS", "Super" and "Hyper" with platform information. It doesn't make sense for me. Additionally, Linux's Meta key and Command key of Mac are really different key. On the other hand, I believe that Win logo key on Windows, Command key on Mac and Super/Hyper key on Linux are really different functional key. Therefore, I feel it's very strange we use same key names for different functional keys. I think that if you believe that "Super" and "Hyper" should be used on Linux, "Meta" shouldn't be used for command key on Mac. I think D3E should define "Command" key name for it. And of course, I think "OS" is better for windows logo key on Windows. Anyway, making XP level modifier key unification includes a lot of conflict by seeing from different angles.
So you would prefer: "Command" (only used on Mac) "OS" (only used on Windows) "Meta", "Super", "Hyper" (only used on Linux) The issue then is what to do with the metaKey attribute? Have 5 separate attributes: commandKey, osKey, metaKey, superKey, hyperKey?
(In reply to comment #4) > So you would prefer: > > "Command" (only used on Mac) > "OS" (only used on Windows) > "Meta", "Super", "Hyper" (only used on Linux) If D3E defines .key indicates current *function*, I think so. But on the other hand, it may not be useful for web developer for such low level information because it means they need to think each platform's culture (e.g., which keys are good for this situation?). > The issue then is what to do with the metaKey attribute? Have 5 separate > attributes: commandKey, osKey, metaKey, superKey, hyperKey? I think that the attributes should be deprecated. So, I don't think D3E should add new attributes for them anymore. I think that .getModifierState() should be better for compatibility with older web browsers in the future.
This issue is now being tracked in 23906 since it describes our solution to this issue. *** This bug has been marked as a duplicate of bug 23906 ***