Note:<\/strong> Events are normally used in combination with functions, and the function will not be executed before the event occurs!<\/p>\n I will give you some example scripts for reading out event properties. There are very serious browser incompatibilities in this area. As soon as we want to read out information about the event, we\u2019re inundated by an immense amount of properties, most of which do not work in most browsers. See the\u00a0Event compatibility tables<\/a> for a quick overview or the\u00a0W3C DOM Compatibility – Events<\/a> page for a complete overview.<\/p>\n I am not going to give an alphabetical list of properties, since it wouldn\u2019t help a bit to make you understand all this \u2014 the situation is too confusing. Instead I\u2019ve written five scripts to ask five questions of the browser.<\/p>\n Please note that in these scripts I\u2019ve been very strict in my object detection. I first create cross-browser event access, then I check if the browser supports each individual property before using it.<\/p>\n This is the only question with a true cross-browser answer: use the\u00a0 [code language=”javascript”] W3C\/Netscape says: the\u00a0 The last two lines of code are especially for Safari. If an event takes place on an element that contains text, this\u00a0text node<\/em>, and not the element, becomes the target of the event. Therefore we check if the target’s Even if an event\u00a0is captured or bubbles up<\/a>, the target\/srcElement always remains the element the event took place on.<\/p>\n There are some more targeting properties. I discuss\u00a0 This one is relatively easy. First get the code of the key (a = 65) from the When you\u2019ve read out the key code, send it through the method [code language=”javascript”] There are some subtleties that may make the key events hard to use. For instance, the\u00a0 There are two properties for finding out which mouse button has been clicked:\u00a0 Now\u00a0 According to Microsoft its values should be:<\/p>\n No doubt the Microsoft model is better than W3C\u2019s. 0 should mean \u201cno button pressed\u201d, anything else is illogical.<\/p>\n Besides, only in the Microsoft model button values can be combined, so that 5 would mean \u201cleft and middle button\u201d. Not even Explorer 6 actually supports this yet, but in the W3C model such a combination istheoretically impossible<\/em>: you can never know whether the left button was also clicked.<\/p>\n In my opinion\u00a0W3C<\/a> has made some serious mistakes in defining\u00a0 Fortunately you most often want to know if the right button has been clicked. Since W3C and Microsoft happen to agree on this one and give Please note that, although Macs have only one mouse button, Mozilla gives a Ctrl\u2013Click a\u00a0 As to the mouse position, the situation is horrible. Although there are no less than six mouse coordinates property pairs, there is no reliable cross\u2013browser way to find the mouse coordinates relative to the document we need.<\/p>\n These are the six property pairs \u2014 see also the\u00a0Event compatibility tables<\/a> or the\u00a0W3C DOM Compatibility – Events<\/a> page.<\/p>\n I explained the problem, W3C\u2019s vagueness and the use of\u00a0 The\u00a0![\"\"](\"http:\/\/www.permadi.com\/tutorial\/jsEventBubbling\/images\/eventcapandbubbling.gif\" "\\"event")
<\/p>\n\n
What is the type of the event?<\/h3>\n
type<\/code>property to read out the type:<\/p>\n
\nfunction doSomething(e)
\n{
\n if (!e) var e = window.event; alert(e.type);
\n}
\n[\/code]<\/p>\nWhich HTML element is the target of the event?<\/h3>\n
target<\/code>. No, says Microsoft, the\u00a0srcElement<\/code>. Both properties return the HTML element the event took place on.
\n[code language=”javascript”]
\nfunction doSomething(e) {
\n\tvar targ;
\n\tif (!e) var e = window.event;
\n\tif (e.target) targ = e.target;
\n\telse if (e.srcElement) targ = e.srcElement;
\n\tif (targ.nodeType == 3) \/\/ defeat Safari bug
\n\t\ttarg = targ.parentNode;
\n}
\n[\/code]<\/p>\nnodeType<\/code> is 3, a text node. If it is we move to its parent node, the HTML element.<\/p>\nOther targets<\/h4>\n
currentTarget<\/code> on the\u00a0Event order<\/a> page and\u00a0relatedTarget<\/code>,\u00a0fromElement<\/code> and\u00a0toElement<\/code> on the\u00a0Mouse events<\/a> page.<\/p>\nWhich key has been pressed?<\/h3>\n
keyCode<\/code> property.<\/p>\nString.fromCharCode()<\/code> to obtain the actual key value, if necessary.<\/p>\n
\nfunction doSomething(e) {
\n\tvar code;
\n\tif (!e) var e = window.event;
\n\tif (e.keyCode) code = e.keyCode;
\n\telse if (e.which) code = e.which;
\n\tvar character = String.fromCharCode(code);
\n\talert('Character was ' + character);
\n}
\n[\/code]<\/p>\nkeypress<\/code> event fires as long as the user keeps the key pressed. However, in most browsers the\u00a0keydown<\/code> event also keeps firing as long as the key is pressed. I\u2019m not sure this is a good idea, but it\u2019s what happens.<\/p>\nWhich mouse button has been clicked?<\/h3>\n
which<\/code> and\u00a0button<\/code>. Please note that these properties don\u2019t always work on a\u00a0click<\/code> event. To safely detect a mouse button you have to use the\u00a0mousedown<\/code> or\u00a0mouseup<\/code> events.<\/p>\nwhich<\/code> is an old Netscape property. Left button gives a value of 1, middle button (mouse wheel) gives 2, right button gives 3. No problems, except its meager support (and the fact that it\u2019s also used for key detection).<\/p>\nbutton<\/code> has been fouled up beyond all recognition. According to W3C its values should be:<\/p>\n\n
\n
button<\/code>.<\/p>\nRight click<\/h4>\n
button<\/code> a value of 2, you can still detect a right click.<\/p>\nfunction doSomething(e) {\r\n\tvar rightclick;\r\n\tif (!e) var e = window.event;\r\n\tif (e.which) rightclick = (e.which == 3);\r\n\telse if (e.button) rightclick = (e.button == 2);\r\n\talert('Rightclick: ' + rightclick); \/\/ true or false\r\n}<\/pre>\nbutton<\/code> value of 2, since Ctrl\u2013Click also brings up the context menu. iCab doesn\u2019t yet support mouse button properties at all and you cannot yet detect a right\u2013click in Opera.<\/p>\nMouse position<\/h3>\n
\n
pageX\/Y<\/code> andclientX\/Y<\/code> in my slightly outdated\u00a0Evolt article<\/a>.<\/p>\nscreenX<\/code> and\u00a0screenY<\/code> properties are the only ones that are completely cross\u2013browser compatible. They give the mouse position relative to the entire computer screen of the user. Unfortunately this information is completely useless: you never need to know the mouse position relative to the screen \u2014 well, maybe only if you want to place another window at the mouse position.<\/p>\n