By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,135 Members | 1,135 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,135 IT Pros & Developers. It's quick & easy.

Getting the Key Code from a Keyboard Event

P: n/a
Hi,
I've been looking up lots of documentation and trying to work out a
cross-platform method of capturing a keyboard event and working out
which key was pressed. From what I can find, there doesn't appear to be
any standardised keyboard event interface other than this DOM 3 Events
W3C Working Group Note [1]. However, it is only a note and doesn't
appear to be implemented in any browser. Is there another standard that
I've missed?

The Gecko DOM Reference lists event.keyCode [2], but this doesn't appear
to be implemented in Firefox 1.0.2, as e.keyCode in the following
returns 0, regardless of the key pressed.

function test(e) {
if (!e) {
e = event;
}
alert(e.keyCode);
}
document.onkeypress = test;

That works in IE and Opera, but IE needed the e = event statement, as it
seems IE doesn't pass an event object to the funciton like Mozilla and
Opera do.
I noticed Eric Meyer's S5 script makes use of key.which in function
keys(key) {...}

key.which seems to work in Firefox and Opera, but not IE, although it
does in S5 because it sets:

key.which = key.keyCode

However, I can't find any documentation for this property anywhere, on
either the Mozilla or Opera sites.

So, my question is, what is the most interoperable method to determine
the key pressed that works in at least Mozilla, Opera, IE and Safari
(though, I don't have Safari available to test in), but preferably that
works in most (if not all) modern browsers available. I generally like
to avoid proprietary extensions, but it seems (as there I don't believe
there is as official standard yet) that I may have no choice in the
matter :-(, so please correct me if I am wrong about this.

[1]
http://www.w3.org/TR/2003/NOTE-DOM-L...nts-Interfaces
[2] http://www.mozilla.org/docs/dom/domr...4.html#1003563
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox
Jul 23 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a


Lachlan Hunt wrote:
I've been looking up lots of documentation and trying to work out a
cross-platform method of capturing a keyboard event and working out
which key was pressed. From what I can find, there doesn't appear to be
any standardised keyboard event interface other than this DOM 3 Events
W3C Working Group Note [1]. However, it is only a note and doesn't
appear to be implemented in any browser. Is there another standard that
I've missed?
No, when the W3C DOM Level 2 Events specification was written the key
events part was postponed for a later level as it became clear that
within Level 2 there wouldn't be any agreement. But even in Level 3 not
more than the note was developed before the whole DOM working group
dissolved.
The Gecko DOM Reference lists event.keyCode [2], but this doesn't appear
to be implemented in Firefox 1.0.2, as e.keyCode in the following
returns 0, regardless of the key pressed.

function test(e) {
if (!e) {
e = event;
}
alert(e.keyCode);
}
document.onkeypress = test;
Mozilla uses two properties, one named charCode which is set when a key
with a character is pressed (e.g. the single quote character "'" with
Unicode character code 39), and the other named keyCode when a key with
a non-character is pressed (e.g. on some keyboards the right arrow key
with key code 39).
I am not sure whether this is just a solution the Mozilla developers
came up with due to a lack of specification when they needed to
implement key events or whether a very early draft of the W3C DOM Level
2 Events spec made any such suggestion.
That works in IE and Opera, but IE needed the e = event statement, as it
seems IE doesn't pass an event object to the funciton like Mozilla and
Opera do.
Right, IE has its own approach with setting a global
window.event
property to the current event object with the current event properties,
I think partly because IE on Win supports other scripting languages like
VBScript and there were difficulties in having VBScript event handlers
take that automatic event attribute.
I noticed Eric Meyer's S5 script makes use of key.which in function
keys(key) {...}
event.which
is part of the Netscape 4 event model and while Mozilla has its own
event model respectively the W3C DOM Level 2 event model the which
property was carried over to allow some backwards compatibility.

So, my question is, what is the most interoperable method to determine
the key pressed that works in at least Mozilla, Opera, IE and Safari
(though, I don't have Safari available to test in), but preferably that
works in most (if not all) modern browsers available.


There is not one interoperable method, IE for instance fires the three
different key events (keydown, keypress, keyup) not consistently for all
keys but only certain events for certain keys, see the documentation on
MSDN for details:
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/events/onkeydown.asp>
it event depends on the IE version.

If you are only interested in character keys then probably
document.onkeypress = function (evt) {
evt = evt || window.event;
var keyCode = evt.keyCode ? evt.keyCode :
evt.charCode ? evt.charCode : evt.which;
};
is a quick hack trying to give you some interoperability to find that
code for the key.

But if you for instance need to know whether the 39 you get that way is
from a right arrow key or a single quote then you are in trouble.

Of course part of that mess is not specific to JavaScript, there are all
type of input devices and different platforms, I have not looked into
Java's key event handling in detail myself but have seen complaints
there that for instance the sequence of keydown/press/up events is
platform specific.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Jul 23 '05 #2

P: n/a
Martin Honnen wrote:


Lachlan Hunt wrote:
...other than this DOM 3 Events W3C Working Group Note [1]...
Is there another standard that I've missed?
No, when the W3C DOM Level 2 Events specification was written the key
events part was postponed for a later level as it became clear that
within Level 2 there wouldn't be any agreement. But even in Level 3 not
more than the note was developed before the whole DOM working group
dissolved.


Oh, great! So, there's basically no chance that this awful situation
will be resolved and we'll have standardisation any time soon. :-(
Mozilla uses two properties, one named charCode which is set when a key
with a character is pressed (e.g. the single quote character "'" with
Unicode character code 39), and the other named keyCode when a key with
a non-character is pressed (e.g. on some keyboards the right arrow key
with key code 39).
Ok, I ran some more tests with the keyup, keypress and keydown events
and tested e.which, e.keyCode and e.charCode, and these are the results
I got, with little consistency between browsers.

Firefox 1.0.2
Key: apostrophe (')
Event e.which e.keyCode e.charCode
keyDown: 222 222 0
keyPress: 39 0 39
keyUp: 222 222 0

Key: Right Arrow
Event e.which e.keyCode e.charCode
keyDown: 39 39 0
keyPress: 0 39 0
keyUp: 39 39 0

Opera 8 (beta 3) (e.charCode not supported)
Key: apostrophe (')
Event e.which e.keyCode
keyDown: 39 39
keyPress: 0 39
keyUp: 39 39

Key: Right Arrow
Event e.which e.keyCode
keyDown: 39 39
keyPress: 39 39
keyUp: 39 39

IE 6 WinXP-SP2 (e.which and e.charCode not supported)
Key: apostrophe (')
Event e.keyCode
keyDown: 222
keyPress: 39
keyUp: 222

Key: Right Arrow
Event e.keyCode
keyDown: 39
keyPress: 39
keyUp: 39

But if you for instance need to know whether the 39 you get that way is
from a right arrow key or a single quote then you are in trouble.
Bugger! I actually do need to know the difference between them, but as
the results above show:
For Firefox: I can compare .keyCode with either .charCode or .which.
For Opera: I can compare .keyCode with .which
For IE: I need to compare .keyCode between the keyPress and
either keyDown or keyUp events.

The difficulty will be with coming up with an algorithm to do it, and
there may be more difficulties if other browsers like Safari aren't
compatible with either the FF, Opera or IE implementation; and I'd
really like it to be done without browser sniffing.
Of course part of that mess is not specific to JavaScript, there are all
type of input devices
Yes I know, but the documents this is intended for should provide
alternatives. The keyboard should not be necessary to use such
applications, this is only intended to be an enhancment for those that do.
and different platforms


Which is why I wish there were some standardisation.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox
Jul 23 '05 #3

P: n/a
Your table of keystroke values is quite nice and informative, thanks
for posting it. I would like to suggest that code trying to decipher
the values should account for the key being held down (ie. the
apostrophe or right arrow key could be held down so that they fire
multiple times). In this case you don't get the key down / key up
being repeated.

My two cents worth,
Csaba Gabor from Vienna

Lachlan Hunt wrote:
Martin Honnen wrote:


Lachlan Hunt wrote:
...other than this DOM 3 Events W3C Working Group Note [1]...
Is there another standard that I've missed?

No, when the W3C DOM Level 2 Events specification was written the key
events part was postponed for a later level as it became clear that
within Level 2 there wouldn't be any agreement. But even in Level 3
not more than the note was developed before the whole DOM working
group dissolved.

Oh, great! So, there's basically no chance that this awful situation
will be resolved and we'll have standardisation any time soon. :-(
Mozilla uses two properties, one named charCode which is set when a
key with a character is pressed (e.g. the single quote character "'"
with Unicode character code 39), and the other named keyCode when a
key with a non-character is pressed (e.g. on some keyboards the right
arrow key with key code 39).

Ok, I ran some more tests with the keyup, keypress and keydown events
and tested e.which, e.keyCode and e.charCode, and these are the results
I got, with little consistency between browsers.

Firefox 1.0.2
Key: apostrophe (')
Event e.which e.keyCode e.charCode
keyDown: 222 222 0
keyPress: 39 0 39
keyUp: 222 222 0

Key: Right Arrow
Event e.which e.keyCode e.charCode
keyDown: 39 39 0
keyPress: 0 39 0
keyUp: 39 39 0

Opera 8 (beta 3) (e.charCode not supported)
Key: apostrophe (')
Event e.which e.keyCode
keyDown: 39 39
keyPress: 0 39
keyUp: 39 39

Key: Right Arrow
Event e.which e.keyCode
keyDown: 39 39
keyPress: 39 39
keyUp: 39 39

IE 6 WinXP-SP2 (e.which and e.charCode not supported)
Key: apostrophe (')
Event e.keyCode
keyDown: 222
keyPress: 39
keyUp: 222

Key: Right Arrow
Event e.keyCode
keyDown: 39
keyPress: 39
keyUp: 39

But if you for instance need to know whether the 39 you get that way
is from a right arrow key or a single quote then you are in trouble.

Bugger! I actually do need to know the difference between them, but as
the results above show:
For Firefox: I can compare .keyCode with either .charCode or .which.
For Opera: I can compare .keyCode with .which
For IE: I need to compare .keyCode between the keyPress and
either keyDown or keyUp events.

The difficulty will be with coming up with an algorithm to do it, and
there may be more difficulties if other browsers like Safari aren't
compatible with either the FF, Opera or IE implementation; and I'd
really like it to be done without browser sniffing.
Of course part of that mess is not specific to JavaScript, there are
all type of input devices

Yes I know, but the documents this is intended for should provide
alternatives. The keyboard should not be necessary to use such
applications, this is only intended to be an enhancment for those that do.
and different platforms

Which is why I wish there were some standardisation.

Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.