3.1. Alphabetical Event Reference
Fires if an img element's content fails to complete loading due to user interruption (e.g., clicking Stop or rapidly navigating to another page) or other failure (e.g., timeout due to network traffic). The W3C DOM applies this event only to the object element, which, in the W3C standards view (but not yet widely supported in browsers), is the desired way to embed an image into a page.
Typical Targets The img element.
Fires when an object becomes the active object. Giving an object focus makes it active, but a rendered element can be the active element without having focus. Only one element at a time may be active. See the setActive( ) method of shared objects in Chapter 2. If an element has received focus, the activate event fires before the focusin and then the focus events.
Typical Targets All rendered elements, plus the document and window objects.
Fires after the user clicks the Print button in the Print dialog box before content is assembled for the printer (beforeprint) and after the data has been sent to the printer (afterprint). You can use these events to trigger functions that modify a style sheet or other content rendering of a page (so that a potentially different-looking page reaches the printer) and then restore the page for viewing on the screen. This technique can work in lieu of style sheet media settings.
Typical Targets The body and frameset elements, plus the window object.
Fires after data being sent to a writable data source object (through the IE data binding mechanism) has successfully updated the database.
Typical Targets Elements that accept data input and support data binding.
Fires just before an object is to become the active object. Giving an object focus makes it active, but a rendered element can be the active element without having focus. Only one element at a time may be active. See the setActive( ) method of shared objects in Chapter 2. If an element received focus, related events fire in the following sequence: beforeactivate, activate, focusin, and focus. If you cancel the beforeactivate event, the element does not become active, nor does it receive focus, but only if the intended focus action occurs from explicit user action (clicking and tabbing). An element blocked from receiving focus causes the focus to go to another element: to the next focusable element in tabbing order (when the user tabs to the blocked element) or to the next outermost focusable parent element in the document tree (when a user clicks on the blocked element). Activating or giving focus to an element via the setActive( ) or focus( ) method cannot be blocked by canceling this event.
Typical Targets All rendered elements, plus the document and window objects.
Fires just before a user-initiated Copy command (via the Edit menu, a keyboard shortcut, or a context menu) completes the task of moving the selected content to the system clipboard. At this point in the copy sequence, a function invoked by this event handler can perform additional or substitute processing for the normal system copy action. For example, additional information from the element, such as effective style information of the element containing selected text, can be preserved in the IE clipboardData object (see Chapter 2) for later processing with the help of the beforepaste event handler. Canceling the beforecopy event does not prevent user copying of a selection. In Internet Explorer, the "before" events fire when the user displays the context menu (i.e., before any menu item is chosen). The events fire in the sequence beforecut, beforecopy, and beforepaste. Moreover, with the context menu approach, the three-event sequence fires twice. Note that in Safari 1.3/2, you must pass onbeforecopy (rather than beforecopy) to addEventListener( ) to bind the event.
Typical Targets Rendered elements except form controls.
Fires just before a user-initiated Cut command (via the Edit menu, a keyboard shortcut, or a context menu) completes the task of removing the content from its current location and moving the selected content to the system clipboard (assuming the browser is in edit mode for body content). At this point in the cut sequence, a function invoked by this event handler can perform additional or substitute processing for the normal system cut action. For example, additional information from the element, such as effective style information of the element containing selected text, can be preserved in the IE clipboardData object (see Chapter 2) for later processing with the help of the beforepaste event handler. Canceling the beforecut event does not prevent user cutting of a selection. See beforecopy for additional browser-specific notes.
Typical Targets All rendered elements.
Fires just before an object is about to yield activation to another object because the user clicked on another element, tabbed to another element, or because a script invoked the setActive( ) or focus( ) method of another element. If an element has focus and is the active element, the following event sequence fires en route to losing focus: beforedeactivate, deactivate, and blur. Because beforedeactivate is cancelable (but deactivate is not), cancel this event to prevent an element from deactivating or losing focusprovided you have a good reason to do this other than annoying your visitors.
Typical Targets All rendered elements, plus the document and window objects.
Fires just before an editable element receives official focus by a user clicking or tabbing to the element. Editable elements include text-oriented form controls and body elements set to be editable (see the IE 5.5 contentEditable property of all elements in Chapter 2). A function invoked from this event handler can perform additional scripted actions, such as setting the color of the element text, before the user begins editing the content.
Typical Targets Text form controls; rendered elements in edit mode (IE 5.5 or later); content governed by the DHTML Editing ActiveX control (see http://msdn.microsoft.com/workshop/browser/mshtml/).
Fires just before a user-initiated Paste command (via the Edit menu, a keyboard shortcut, or a context menu) completes the task of pasting the content from the system clipboard to the current selection. If you are trying to paste custom information from the clipboardData object (saved there in an beforecopy, copy, beforecut, or cut event handler), you need to have the beforepaste and paste event handler functions working together. Set event.returnValue to false in the beforepaste event handler so that the Paste item in the Edit (and context) menu is activated, even for a noneditable paste target. When the user selects the Paste menu choice, your paste event handler retrieves information from the clipboardData object and perhaps modifies the selected element's HTML content: function handleBeforePaste( ) { event.returnValue = false; } function handlePaste( ) { if (event.srcElement.className == "OK2Paste") { event.srcElement.innerText = clipboardData.getData("Text"); } }
In the above paste operation, the system clipboard never plays a role because your scripts handle the entire data transferall without having to go into edit mode. See beforecopy for additional browser-specific notes.
Typical Targets All rendered elements and the document object.
See afterprint.
Fires just before the current document begins to unload due to impending navigation to a new page, form submission, or window closure. This event fires before the unload event, and gives your scripts and users a chance to cancel the unload action. Some of this activity is automatic to prevent nefarious scripts from trapping users on a page. In the beforeunload event handler, assign a string to the event.returnValue property to force IE and Mozilla 1.8 or later to display a dialog box that lets the user choose whether the page should stay where it is, or whether the navigation or window closure action that the user requested continues as expected. The string assigned to the event property becomes part of the dialog box message (other text in the message is hard-wired by the browser and may not be removed or modified). The resulting action is controlled by the user's button choice in the dialog box.
Typical Targets The body and frameset elements, plus the window object.
Fires just prior to sending data to a writable data source object (through the IE data binding mechanism). You can perform data validation and cancel the update.
Typical Targets Elements that accept data input and support data binding.
Fires after the current element loses focus (due to some other element receiving focus) or invoking the blur( ) method of the current element. The blur event fires before the focus event in the other element. Avoid using the blur event in text input fields to trigger form validation, especially if the validation routine displays an alert dialog box upon discovering an error. Interaction among the blur and focus events, along with the display and hiding of an alert dialog box can put you into an infinite loop. Use change instead. Although the blur event has been supported for form controls and window objects since the early days of scriptable browsers, modern browsers can fire the event on virtually any other rendered element, provided the tabindex attribute is set for the element. Note that IE for Windows is known to omit firing the blur event on window objects.
Typical Targets For all browsers, input (of type text and password), textarea, select, and window objects; for IE 5 or later and W3C DOM browsers, add any rendered element for which the tabindex attribute is assigned a value.
Fires each time the text in a marquee element, whose behavior is set to alternate, touches a boundary and changes direction.
Typical Targets The marquee element.
Fires on the element hosting a data binding data source object (usually the object element) each time data in the remote database changes its value.
Typical Targets The object and applet elements.
Fires when a text-oriented form control or select element loses focus and its content or chosen item is different from what it was when the element most recently gained focus. Use this event in text-type input and textarea elements to validate an entry for that one field. But also include form-wide validation with the form element's submit event handler. This event fires before the blur event.
Typical Targets Text-type input, textarea, and select elements.
Fires after the user effects a mouse click or equivalent action. Click equivalents occur naturally on focusable elements (buttons and links for most browsers) by pressing the Enter key (and frequently the spacebar) when the item has focus. In modern browsers that support the accesskey attribute, typing the access key combination also triggers a click equivalent. For mouse click actions, the click event fires only if the mouse button is pressed and released with the pointer atop the same element. In that case, the primary mouse events fire in this order: mousedown, mouseup, and click. An event object created from a mouse event has numerous properties filled with details such as coordinates of the click and whether any modifier keys were held down during the event. Information about the button used is more reliably accessed through the mousedown or mouseup event. The event handler function can inspect these properties as needed. Although the click event has been supported for button-oriented form controls and link objects since the early days of scriptable browsers, modern browsers can fire the event on virtually any other rendered element. Note that in Mozilla versions prior to 1.4 and Safari prior to 1.3, mouse events can fire on child text nodes of container-type elements, meaning that the event object's target property references the node, rather than the element. See Online Section VI for details about the impact of this behavior and cross-browser solutions.
Typical Targets For all browsers, input (of type button, radio, checkbox, reset, and submit), a, and area objects; Version 4 and later support the event for the document and window objects; for IE 4 or later and most W3C DOM browsers (not Opera 9), add any rendered element, as well as text nodes for Mozilla prior to version 1.4.
Fires after the user clicks the right mouse button (or the button designated the secondary mouse button in the mouse control panel). This mouse button displays the context menu for the item beneath the pointer. For Mozilla prior to 1.4 and Safari prior to 1.3, the event target could be a text node. For all other supporting browsers and versions, the target (or IE event.sourceElement) is the containing element. To block the display of the context menu (and perhaps display a custom one of your own design via DHTML), set event.returnValue to false in the contextmenu event handler. While hiding the context menu may make it more difficult for users to view the source of a page or save an image (assuming you have already opened a document in a window bereft of the menubar), it is not a foolproof way to guard against determined users capturing your page's content. Any scripted solution fails the instant the user disables scripting.
Typical Targets All rendered elements and the document object.
Fires when the user selects an editable element (not its content) while the page is in edit mode. See move for a demonstration of this event.
Typical Targets All rendered elements and the document object.
Fires after the user initiates the Copy command (via the Edit menu, a keyboard shortcut, or a context menu) to place a copy of the selected content into the system clipboard. An event handler function for this event can supplement the copy action by placing additional data of your choice into the clipboardData object (which the paste event handler can read and handle as needed). To give users access to a Copy menu command for an otherwise uneditable element, set event.returnValue to false in the beforecopy event handler for the same object as the copy event handler. On the other hand, to prevent user copying of body content, set event.returnValue to false for the copy event handler. Just don't regard this tactic as a foolproof way to prevent users from copying your prized content. Note that in Safari 1.3/2, you must pass oncopy (rather than copy) to addEventListener( ) to bind the event.
Typical Targets Rendered elements except form controls.
Fires after the user initiates the Cut command (via the Edit menu, a keyboard shortcut, or a context menu) to place a copy of the selected content into the system clipboard. To cut body content, the containing element must be in edit mode (see the shared contendEditable property in Chapter 2). An event handler function for this event can supplement the cut action by placing additional data of your choice into the clipboardData object (which the paste event handler can read and handle as needed). To give users access to a Cut menu command for an otherwise uneditable element, set event.returnValue to false in the beforecut event handler for the same object as the cut event handler. On the other hand, to prevent user cutting of body or form control content, set event.returnValue to false for the cut event handler. Note that in Safari 1.3/2, you must pass oncut (rather than cut) to addEventListener( ) to bind the event.
Typical Targets All rendered elements.
Fire on the element hosting a data binding data source object (usually the object element) each time the remote data source signals it has new data ready for retrieval (dataavailable), a data set has been modified (datasetchanged), or a data set has received all data form the query (datasetcomplete). These events are available only for data source object types capable of asynchronous connections with their remote sources.
Typical Targets The object and applet elements; the xml element in IE 5 and later.
Fires after the user effects a second successive mouse click or equivalent action (see click for click equivalents). A double-click requires a specific sequence of mouse events leading up to it. The sequence is mousedown, mouseup, click, mouseup, and dblclick. The amount of time that can elapse between the two clicks is determined by the client computer's mouse control panel settings. Because the click event fires ahead of dblclick, the associated click event handler (if any) should perform only innocuous actions, such as highlighting an element, much like the way operating system desktop icons operate. If an item requires a double-click, that is the only event that should do something significant. For Mozilla prior to 1.4 and Safari prior to 1.3, the event target could be a text node. For all other supporting browsers and versions, the target (or IE event.sourceElement) is the containing element.
Typical Targets Support for this event in Navigator 4 is limited to the a element (but not on the Macintosh); IE 4 or later and W3C DOM browsers (except Safari through version 2) support the event on renderable elements and the document object.
Fires after an object has yielded activation to another object because the user clicked on another element or tabbed to another element, or because a script invoked the setActive( ) or focus( ) method of another element. If an element has focus and is the active element, the following event sequence fires en route to losing focus: beforedeactivate, deactivate, and blur. To prevent an element from deactivating or losing focus, cancel the companion beforedeactivate event.
Typical Targets All rendered elements, plus the document and window objects.
Fires when a user begins interacting with an element, such as clicking a button or typing a character into a text box. The event object's detail property passes an integer that contains more information about the event: 1 for unmodified single clicks; 2 for actions with modifier keys or double-clicks (what the DOM specification calls hyperactivation).
Typical Targets All rendered elements that are capable of receiving focus normally (such as form controls and links), plus any other rendered element for which the tabindex attribute is assigned a value.
Fires after a script adds, removes, or changes the value of an element's attribute. Adding or removing an attribute must be done by the setAttribute( ) and removeAttribute( ) methods, but changing an existing attribute may be accomplished either by the setAttribute( ) method or assigning a new value to an element object's property that corresponds to an attribute. Numerous event object properties convey details about the event. See the following properties of the event object in Chapter 2: attrName, attrChange, prevValue, newValue, and relatedNode.
Typical Targets All elements.
Fires after a script changes the value of a CharacterData type of node. See the following properties of the event object in Chapter 2: prevValue and newValue.
Typical Targets CharacterData nodes.
Fires immediately after all HTML source code has been interpreted by the browser such that all elements are represented in the DOM. This occurs ahead of further loading of external content (e.g., images, sounds, etc.) that may require more time to completeafter which the load event fires. Using this event instead of load allows DHTML scripts to begin modification of the document tree even while other external content is en route. The event does not fire if the user navigates to the page via the browser history (e.g., Back or Forward buttons).
Typical Targets body, document, window DOM objects.
Fires on a Web Forms 2.0 form control each time its value changes. Binding this event to a form element lets a script execute when any single control's value changes.
Typical Targets Web Forms 2.0 form control elements and the form element.
Fires when the current element receives focus (DOMFocusIn) or loses focus (DOMFocusOut). These events fire prior to the focus and blur events, respectively. Similar to the IE focusin and focusout events.
Typical Targets All rendered elements that are capable of receiving focus normally (such as form controls and links), plus any other rendered element for which the tabindex attribute is assigned a value.
Fires immediately after all HTML source code loading into a frame element has been interpreted by the browser such that all elements are represented in the DOM. This occurs ahead of further loading of external content (e.g., images, sounds, etc.) that may require more time to completeafter which the load event fires. Using this event instead of load allows DHTML scripts to begin modification of the document tree even while other external content is en route. The event does not fire if the user navigates to the page via the browser history (e.g., Back or Forward buttons). This event is typically bound to frame elements inside the framesetting document.
Typical Target frame element.
Fires on an option element when an option is selected via a keyboard Up or Down arrow key. For example, if you assign an accesskey to a select element and invoke that key combination, the select element forces a focus event. A press of the Up or Down arrow key to choose an option fires the DOMMenuItemActive event.
Typical Target option element.
Fires on a node when that node is explicitly inserted into an existing node container. If you assign an event listener for this event to an element that is the recipient of an inserted (including appended) node, the DOMNodeInserted event fires on the node being inserted (the srcElement of the event object). If the event bubbles further (i.e., away from the point of insertion), the event listener function can still find out about the new container by reading the relatedNode event property. Note that if the incoming node comes from another location in the same document, the removal of the node from its original container fires the DOMNodeRemoved event on the removed node before it leaves its original container (so that the event can bubble up to its original container).
Typical Targets All nodes.
Fires on a node when that node is inserted into an existing node container, but the origin of the node is from another document. If you assign an event listener for this event and the DOMNodeInserted event, the DOMNodeInsertedIntoDocument event fires first. Note that if the incoming node comes from another location in another document, the removal of the node from its original document fires the DOMNodeRemovedFromDocument and DOMNodeRemoved events on the removed node before it leaves its original container (so that the event can bubble up to its original container).
Typical Targets All nodes.
Fires on a node when that node is explicitly removed from a node container. If you assign an event listener for this event to an element that is the container of a removed node, the DOMNodeRemoved event fires on the node being removed (the srcElement of the event object). If the event bubbles further (i.e., away from the original node location), the event listener function can still find out about the old container by reading the relatedNode event property.
Typical Targets All nodes.
Fires on a node when the node is removed because it is being inserted into another document, meaning the node is exiting its original document entirely. If you assign an event listener for this event and the DOMNodeRemoved event, the DOMNodeRemovedFromDocument event fires last.
Typical Targets All nodes.
Fires on a node that is inside the document tree and that changes its nested node structure. This event acts like a generic event for the more specific node mutation events, and fires last.
Typical Targets All nodes.
Fires when a script modifies the value of the document.title property.
Typical Targets document node.
When the user starts dragging a previously created selection, the browser fires one dragstart event on the selection's parent element, followed by a series of drag events, and then one dragend event when the user releases the mouse button. All three event types fire on the same element during the drag. During the drag operation, the user sees the cursor in one of its various forms, rather than seeing the actual element float around the page. As long as the user keeps the mouse button down following an initial drag action, the drag event keeps firing. Other drag-related events fire on other elements along the way (events such as dragenter for an element that finds the dragged cursor in its airspace), but the drag event also fires at various instances. An element with content that is dragged receives events in the following sequence: dragstart, drag (perhaps many times), and dragend. Elements in the path of the drag action receive dragenter, dragover, and dragleave events, while the element at the end of the drag receives the drop event (which fires before the dragend event of the dragged element). The speed of the drag action and client system speed impacts the number of event firings of all drag types. A fast drag on a slow machine may result in some events not firing.
Typical Targets All rendered elements and document objects. Safari fires the events on text nodes.
Fires (in Navigator 4 only) if the user drags a desktop file to the document. With signed scripts, the browser can read the filename of the dragged item.
Typical Targets The window object.
See drag.
Elements in the path of a drag action usually receive dragenter, dragover, and dragleave events in that order. The speed of the drag action and client systems impact the number of event firings of all drag types. A fast drag on a slow machine may result in some events not firing. If your scripts will be performing customized actions upon the user dropping the dragged item onto a target in the document, you should prevent default actions of the dragenter and dragover events so that the target's drop event can do its job without interference from the normal system response to dragging. See the dataTransfer object in Chapter 2 for an example of drag-related event interaction.
Typical Targets All rendered elements and document objects.
See drag.
Fires on the drop target element when the user releases the mouse button after a drag action. Fires just before the dragend event of the owner of the dragged content. Prevent default actions of the drop target's dragenter and dragover events (by setting event.returnValue to false in their respective event handler functions) so that the target's drop event can do its job without interference from the normal system response to dragging. See the dataTransfer object in Chapter 2 for an example of drag-related event interaction, including the effectAllowed property, which controls the cursor shape at the drop target.
Typical Targets All rendered elements and document objects.
Fires after one of a variety of errors occurs, depending on the element or object to which the event handler is assigned. For elements that load external content, such as the img element, errors during loading (such as an invalid URL) fire the error event on the img element. When assigned to the window object (including direct assignment in the <body> tag), overall runtime script errors (not compile-time syntax errors) also fire the error event. A technique that some scripters used in earlier browsers that plastered script error messages inside intrusive alert dialog boxes was to trap all runtime errors in the following manner: function doNothing( ) {return true;} window.onerror = doNothing;
This isn't good for debugging because you need to find errors during development. See the Error object in Chapter 2 for more details on processing errors from this event handler. Eventually, there will enough browsers deployed that use more modern exception handling (see try/catch in Chapter 5).
Typical Targets Elements that load external content, plus the window object and (in Mozilla) XMLHttpRequest.
Fires if an error occurs while sending data to a writable data source object (through the data binding mechanism).
Typical Targets Elements that accept data input and support data binding.
Fires when an element's filter changes its state and when a transition or blend filter completes its action. You can use the event to cascade a sequence of transitions.
Typical Targets Most rendered elements.
Fires after the scrolling text in a looping marquee element comes to rest after its final motion.
Typical Targets The marquee element.
Fires when the current element receives focus due to user action (clicking or tabbing) or invoking of the focus( ) method. The blur event of the next previously focused element fires before the focus event in the current element. Although the focus event has been supported for form controls and window objects since the early days of scriptable browsers, modern browsers can fire the event on virtually any other rendered element, provided the tabindex attribute is set for the element. Note that IE for Windows is known to omit firing the focus event on window objects.
Typical Targets For all browsers, input (of type text and password), textarea, select, and window objects; for IE 5 or later and W3C DOM browsers, add any rendered element for which the tabindex attribute is assigned a value.
Fire when the current element receives focus (focusin) or loses focus (focusout). These events fire prior to the focus and blur events, respectively. Microsoft suggests that you can use these event handlers to perform style changes (anywhere in the document) in anticipation of an element receiving or losing focus, without disturbing the normal focus and blur actions.
Typical Targets All rendered elements that are capable of receiving focus normally (such as form controls and links), plus any other rendered element for which the tabindex attribute is assigned a value.
Web Forms 2.0 event that fires after a form control's change event. But unlike the change event, formchange fires on all other controls in the form (except an output element) in source code order, and then the enclosing form element. Therefore, a form control can "know" when any other control in the form has changed.
Typical Targets Web Forms 2.0 form control elements.
Web Forms 2.0 event that fires after a form control's input event. But unlike the input event, forminput fires on all other controls in the form (except an output element) in source code order, and then the enclosing form element. Therefore, a form control can "know" when any other control in the form is being changed.
Typical Targets Web Forms 2.0 form control elements.
Fires when the user presses the F1 function key. If an element has focus at the time, that is the element that receives the event. You can prevent the default action (displaying the IE Help window) and generate your own DHTML-based help system if you like.
Typical Targets All rendered elements, plus document and window objects, except in IE for Macintosh, which limits this event to the window object.
Web Forms 2.0 event that fires as a user performs any input action on a form control. For example, each keystroke in a text field fires an input event. Thus, scripts can perform more immediate input validation, rather than waiting for an change event to fire upon the element losing focus.
Typical Targets Web Forms 2.0 form control elements.
Web Forms 2.0 event that fires on a form control just prior to the form's submission and the value does not meet the criteria established via other element attributes. See the output element in Chapter 1 for an example.
Typical Targets Web Forms 2.0 form control elements.
Fire when the user presses (keydown) and releases (keyup) a keyboard key. These two events fire on a focusable element or object for almost every key of the keyboard, including function and navigation keys. The instance of the event object for these events contains information about the key (not the character) pressed. See Online Section VI for details on cross-browser handling of keyboard events. You cannot reliably inhibit critical Ctrl character sequences, but if you prevent the default action of the keypress event for a text form control, the character does not arrive at the text field.
Typical Targets All focusable rendered elements, plus document and window objects.
Fires when the user presses a keyboard character key or holds it down until the computer's auto-repeat mechanism takes hold. During auto-repeat, a new event fires prior to each character registering with the system (e.g., for display in a text box). The event sequence is keydown, keypress, and keyup. For text fields, the keypress event fires before the typed character appears in the text box. Therefore, the value of the event target/srcElement has the text prior to the addition of the typed character. See Online Section VI for details on cross-browser handling of keyboard events.
Typical Targets All focusable rendered elements, plus the document object.
Fires when a print preview LayoutRect object finishes rendering its content. For details on this XML enhancement for IE 5.5 and later, visit http://msdn.microsoft.com/workshop/browser/hosting/printpreview/reference/reference.asp.
Typical Targets An XML LayoutRect object.
Fires when external content belonging to the current element or object finishes loading and initializing. This event handler for the window object is perhaps the most important because it signals that all content of the document and its elements (including external content) has loaded before the event fires. When that event fires, your scripts can reference any document tree object without error. See also the DOMContentLoaded event. The event fires for a frameset element only after the load events for all frames have fired (but the event is not bubbling from frame to frameset). Note that if the user or a script loads a new page into a frame after the frameset's initial load, the load event does not fire again for the frameset (but it does for the frame). Although the load event has been supported for window objects since the early days of scriptable browsers, modern browsers fire the event on virtually any other rendered element that loads external content.
Typical Targets For all browsers, window objects; for Version 4 browsers or later the img element; for IE 4 or later and current mainstream browsers, add any rendered element capable of loading external content; for Mozilla 1.8 and Safari 1.2, XMLHttpRequest.
Fires when event capture mode for the element becomes disengaged. See the shared setCapture( ) method in Chapter 2.
Typical Targets All rendered elements.
Fires when one document invokes the postMessage( ) method on another document (e.g., the second document being in an iframe). The event handler to receive and process the event is bound to the destination document object, and the event object's properties convey information such as domain (to help the destination document verify that the event is coming from a desired sender) and data. Data can be only a string value, but the two documents may be served from different domains, bypassing the cross-domain security restrictions of normal JavaScript processing.
Typical Targets document
Fires when the user presses down (mousedown) or releases (mouseup) a mouse button. Events related to mouse click actions fire in this order: mousedown, mouseup, and click. An event object created from a mouse event has numerous properties filled with details such as coordinates of the click, the mouse button used, and whether any modifier keys were held down during the event. The event handler function can inspect these properties as needed. Note that in Mozilla prior to version 1.4 and Safari prior to version 1.3, mouse events can fire on child text nodes of container-type elements, meaning that the event object's target property references the node, rather than the element. See Online Section VI for details about the impact of this behavior and cross-browser solutions.
Typical Targets All rendered elements, except in Navigator 4, where the events are limited to button-style input elements, plus a and area elements.
Fire when the user rolls the mouse pointer into (mouseenter) or out of (mouseleave) an element's space (including border or padding, but not margin). Each event fires just once per entry and exit. These variations on the mouseover and mouseout events do not bubble.
Typical Targets All rendered elements.
Fires while the user rolls the mouse pointer atop an element's space, with the mouse button up or down. Note that the event fires repeatedly, although the frequency of firing depends on the speed of the mouse motion and system resources. An event object created from a mouse event has numerous properties filled with details such as coordinates of the pointer and whether any modifier keys were held down during the event. The event handler function can inspect these properties as needed. In Navigator 4, this event type can be assigned to the window, document, and layer object, but only in the explicitly defined event capture mode. Note that in Mozilla prior to version 1.4 and Safari prior to version 1.3, mouse events can fire on child text nodes of container-type elements, meaning that the event object's target property references the node, rather than the element. See Online Section VI for details about the impact of this behavior and cross-browser solutions.
Typical Targets All rendered elements, except as noted earlier for Navigator 4.
Fire when the user rolls the mouse pointer into (mouseover) or out of (mouseout) an element's space (including border or padding, but not margin). Each event fires just once per entry and exit (except in Navigator 4 for Windows, in which the event fires repeatedly, similar to mousemove). Because the mouseout event doesn't officially fire until another element in the window fires its mouseover event (whether you have a handler for it or not), the mouseout event may not fire if the target element is at the edge of a window or frame, and the user whisks the pointer outside of the current frame without the first frame's body element ever receiving the mouseover event. If you use mouseout events to restore image swaps, the user could see a stuck image. Leave sufficient space around your swappable images to account for this behavior. An event object created from a mouse event has numerous properties filled with details such as coordinates of the click, the mouse button used, whether any modifier keys were held down during the event, and where the incoming pointer came from or outgoing pointer has gone. The event handler function can inspect these properties as needed. Note that in Mozilla prior to version 1.4 and Safari prior to version 1.3, mouse events can fire on child text nodes of container-type elements, meaning that the event object's target property references the node, rather than the element. See Online Section VI for details about the impact of this behavior and cross-browser solutions. Although these events have been supported in one form or another since the early days of scriptable browsers, only modern browsers can fire the event on virtually any rendered element. For older browsers, the events were limited to a and area elements (where a elements surrounded images to be swapped).
Typical Targets All rendered elements, except as noted earlier.
Fires as the user spins the mouse wheel (on a mouse equipped with a wheel). The event object's wheelDelta property reveals details about the direction and amount of rotation.
Typical Targets All rendered elements and the document object.
Fires (in Navigator 4 only) if the user or script moves the browser window.
Typical Targets The window object.
When in edit mode, a positionable element set up for dragging receives these events in the following sequence: movestart (upon starting the drag), move (repeatedly during the drag), and moveend (upon release of the mouse button). The following example uses several events to demonstrate IE edit mode scripting (note that the native element dragging mechanism doesn't work well in IE 6 if the <!DOCTYPE> element points to a standards-compatible mode DTD): <html> <head> <title>IE 5.5 (Windows) Edit Mode</title> <style type="text/css"> body {font-family:Arial, sans-serif} #myDIV {position:absolute; height:100px; width:300px;} .regular {border:5px black solid; padding:5px; background-color:lightgreen} .moving {border:5px maroon dashed; padding:5px; background-color:lightyellow} .chosen {border:5px maroon solid; padding:5px; background-color:lightyellow} </style> <script type="text/javascript"> // built-in dragging support document.execCommand("2D-position",false,true); // preserve content between modes var oldHTML = ""; // engage static edit environment function editOn( ) { var elem = event.srcElement; elem.className = "chosen"; } // engage special edit-move environment function moveOn( ) { var elem = event.srcElement; oldHTML = elem.innerHTML; elem.className = "moving"; } // display coordinates during drag function trackMove( ) { var elem = event.srcElement; elem.innerHTML = "Element is now at: " + elem.offsetLeft + ", " + elem.offsetTop; } // turn off special edit-move environment function moveOff( ) { var elem = event.srcElement; elem.innerHTML = oldHTML; elem.className = "chosen"; } // restore original environment (wrapper gets onfocusout) function editOff( ) { var elem = event.srcElement; if (elem.id == "wrapper") { elem.firstChild.className = "regular"; } } // initialize event handlers function init( ) { document.body.oncontrolselect = editOn; document.body.onmovestart = moveOn; document.body.onmove = trackMove; document.body.onmoveend = moveOff; document.body.onfocusout = editOff; } window.onload = init; </script> </head> <body> <div contenteditable="true"> <div > This is a positioned element with some text in it. </div> </div> </body> </html>
Typical Targets All rendered elements.
Fires after the user initiates the Paste command (via the Edit menu, a keyboard shortcut, or a context menu) to place a copy of the system clipboard into the selected content. An event handler function for this event can supplement the paste action by retrieving additional data from the clipboardData object (information placed there by one of the copy- or cut-related event handler functions). To give users access to a Paste menu command for an otherwise uneditable element, set event.returnValue to false in the beforepaste event handler for the same object as the paste event handler. On the other hand, to prevent user pasting system clipboard content, set event.returnValue to false for the paste event handler.
Typical Targets All rendered elements.
Fires periodically during the receipt of data from the server through the XMLHttpRequest object.
Typical Targets XMLHttpRequest object.
Fires after the property of an element changes under script control. Property changes occur through direct property assignment and methods, such as setAttribute( ). Changes to an element's property (e.g., a property of an element's style object) also trigger this event. The event object's propertyName property contains the name of the property influenced by the event.
Typical Targets All rendered elements, plus the document object.
Fires if the readyState property changes for an element. See the shared readyState property in Chapter 2 for details on what affects the property. Most browsers support this event only for the XMLHttpRequest object (see Online Section VII).
Typical Targets Elements that load external content, including XMLHttpRequest.
Fires when a form element receives a request to reset the form from a reset-type input element or a scripted reset( ) method. By canceling the event, a script in the reset event handler aborts the normal form reset.
Typical Targets The form element.
Fires after an element or object is resized by the user or script control. Note that resizing a window may force other elements in the page to resize themselves. In IE, resize events from those elements bubble to the body and window objects, where a lone resize event handler may be bombarded by events. Safari fires this event on the window object, and not a node in the DOM tree.
Typical Targets For IE, elements that have dimensions associated with them, plus the window and document objects; for Mozilla and Opera, the window and document objects; for Safari, the window object only.
Fire (in edit mode only) when a user resizes an element by dragging its resize handles. See move for a related example.
Typical Targets All rendered elements.
Fire on the element hosting a data binding data source object (usually the object element) when a row in the remote database table is modified either through database or data source activity.
Typical Targets The object and applet elements; the xml element in IE 5 and later.
Fires each time an element displaying scroll bars or the browser window executes a scroll, either by user action or script control. If a user drags the scroll bar thumb, the event fires repeatedly during the dragging motion, but the frequency of event firings depends on system speeds.
Typical Targets All rendered elements that can have scrollbars by default (such as textarea and window objects), plus any element that has its overflow style sheet attribute set to scroll; in Mozilla and Safari, the html element; in Opera, the body element and document node.
Fires when a user drags a selection in a text box (input or textarea elements). Broken in Navigator 4 for Windows. In IE 4 or later for Windows, the event also applies to body text selections.
Typical Targets Text-type input and textarea elements for all browsers; body element for IE 4 or later for Windows.
Fires when the selection type (in IE edit mode) changes.
Typical Targets The document object.
Fires immediately after the user begins dragging a selection on a body element or form control text. If the selection extends across multiple elements, only one event fires, and its target remains the element where the selection began. Canceling this event in the <body> tag (onselectstart="return false") can prevent undesirable and inadvertent user selection and scrolling interaction.
Typical Targets All rendered elements.
Fires when the scrolling text in a looping marquee element begins its motion after a page loads.
Typical Targets The marquee element.
Fires when the user clicks the browser's Stop button, even if the document and its content have successfully loaded.
Typical Targets The document object.
Fires when a form element receives a request to submit the form from a submit-type input element but not from a scripted submit( ) method. This is the event to trigger one final client-side form validation prior to sending a form to the server. By canceling the event, a script in the submit event handler aborts the submission.
Typical Targets The form element.
Fires just before the current document begins to unload due to impending navigation to a new page, form submission, or window closure. This event fires after the beforeunload event in browsers that support that event. In most browsers, the actual document unloading does not wait for the unload event handler function to complete. Therefore, if the function performs too many actions, especially those that rely on script variables and elements in the current page, those references may become invalid while the function runs, creating script errors (of the "undefined" or "object not found" variety). Therefore, keep unload processing to a minimum.
Typical Targets The body and frameset elements, plus the window object. |
