Event.which mouse

Active 4 months ago. Viewed 3k times. My code: div. Improve this question. DavNej DavNej 1 1 silver badge 8 8 bronze badges.

KevinKloet Nopes. It's for keyboard events. For mouse, it's button. Also, keycode is deprecated. No worries.

KevinKloet — Praveen Kumar Purushothaman. PrashanthBenny Are you sure? What does it give? Dude, this is a MouseEvent! What you are telling is a KeyboardEvent! Add a comment. Active Oldest Votes. Improve this answer. Event objects complete these phases as described below. For example, if the bubbles attribute is set to false, the bubble phase will be skipped, and if stopPropagation has been called prior to the dispatch, all phases will be skipped.

This phase is also known as the capturing phase. This phase is also known as the at-target phase. This phase is also known as the bubbling phase. Events are typically dispatched by the implementation as a result of a user action, in response to the completion of a task, or to signal progress during asynchronous activity such as a network request. Some events can be used to control the behavior that the implementation may take next or undo an action that the implementation already took.

Events in this category are said to be cancelable and the behavior they cancel is called their default action. Cancelable event objects can be associated with one or more 'default actions'. To cancel an event, call the preventDefault method. A mousedown event is dispatched immediately after the user presses down a button on a pointing device typically a mouse. One possible default action taken by the implementation is to set up a state machine that allows the user to drag images or select text.

Preventing the default action of a mousedown event prevents these actions from occurring. Default actions are usually performed after the event dispatch has been completed, but in exceptional cases they may also be performed immediately before the event is dispatched. When an event is canceled, then the conditional default actions associated with the event is skipped or as mentioned above, if the default actions are carried out before the dispatch, their effect is undone.

Whether an event object is cancelable is indicated by the cancelable attribute. Calling preventDefault stops all related default actions of an event object. The defaultPrevented attribute indicates whether an event has already been canceled e.

If the DOM application itself initiated the dispatch, then the return value of the dispatchEvent method indicates whether the event object was cancelled. Events which are synchronous sync events are treated as if they are in a virtual queue in a first-in-first-out model, ordered by sequence of temporal occurrence with respect to other events, to changes in the DOM, and to user interaction.

Each event in this virtual queue is delayed until the previous event has completed its propagation behavior, or been canceled.

Some sync events are driven by a specific device or process, such as mouse button events. These events are governed by the event order algorithms defined for that set of events, and user agents will dispatch these events in the defined order.

Events which are asynchronous async events may be dispatched as the results of the action are completed, with no relation to other events, to other changes in the DOM, nor to user interaction. During loading of a document, an inline script element is parsed and executed. The load event is queued to be fired asynchronously at the script element. However, because it is an async event, its order with relation to other synchronous events fired during document load such as the DOMContentLoaded event from [HTML5] is not guaranteed.

Events that are generated by the user agent , either as a result of user interaction, or as a direct result of changes to the DOM, are trusted by the user agent with privileges that are not afforded to events generated by script through the createEvent method, modified using the initEvent method, or dispatched via the dispatchEvent method.

The isTrusted attribute of trusted events has a value of true , while untrusted events have a isTrusted attribute value of false.

Most untrusted events will not trigger default actions , with the exception of the click event. This event always triggers the default action , even if the isTrusted attribute is false this behavior is retained for backward-compatibility.

All other untrusted events behave as if the preventDefault method had been called on that event. Certain event targets such as a link or button element may have associated activation behavior such as following a link that implementations perform in response to an activation trigger such as clicking a link.

An activation trigger is a user action or an event which indicates to the implementation that an activation behavior should be initiated. User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element a hotkey or access key even when that element does not have focus.

Event-based activation triggers may include timer-based events that activate an element at a certain clock time or after a certain time period has elapsed, progress events after a certain action has been completed, or many other condition-based or state-based events. Generally, when a constructor of an Event interface, or of an interface inherited from the Event interface, is invoked, the steps described in [DOM] should be followed. This section supplements the DOM4 steps for intializing a new Event object with these optional modifier states.

For the purposes of constructing a KeyboardEvent , MouseEvent , or object derived from these objects using the algorithm below, all KeyboardEvent , MouseEvent , and derived objects have internal key modifier state which can be set and retrieved using the key modifier names described in the Modifier Keys table in [UIEvents-Key].

If the Event being constructed is a KeyboardEvent or MouseEvent object or an object that derives from either of these, and a EventModifierInit argument was provided to the constructor, then run the following sub-steps:.

These basic event interfaces MUST always be supported by the implementation:. The Event interface and its following constants, methods and attributes:. NONE constant. The CustomEvent interface and its following method and attribute:. The EventTarget interface and its following methods:. The EventListener interface and its handleEvent method. The event types defined in this specification derive from these basic interfaces, and MUST inherit all of the attributes, methods, and constants of the interfaces they derive from.

The following chart describes the inheritance structure of the interfaces described in this specification. Each event MUST be associated with a type, called event type and available as the type attribute on the event object.

Depending on the level of DOM support, or the devices used for display e. When used with an [XML] or [HTML5] application, the specifications of those languages MAY restrict the semantics and scope in particular the possible event targets associated with an event type. Refer to the specification defining the language used in order to find those restrictions or to find event types that are not defined in this document. The following table provides an informative summary of the event types described in this specification.

For a list of events which are deprecated in this specification, see the Legacy Event Types appendix at the end of this document. The following is one way to interpret the above tables: the load event will trigger event listeners attached on Element nodes for that event and on the capture and target phases.

This event is not cancelable. If an event listener for the load event is attached to a node other than Window , Document , or Element nodes, or if it is attached to the bubbling phase only, this event listener would not be triggered. Similarly, dispatchEvent can be used to dispatch untrusted events to listeners on any object that also implements EventTarget.

The event objects associated with the event types described above contain additional context information--refer to the description of the DOM interfaces for further information. The model has been designed to allow addition of new event modules in the future. This document does not attempt to define all possible events. For purposes of interoperability, the DOM defines a module of user interface events including lower level device dependent events and a module of document mutation events.

The User Interface event module contains basic event types associated with user interfaces and document manipulation. The UIEvent interface provides specific contextual information associated with User Interface events. Inherit only when members of UIEventInit make sense to those events. The un-initialized value of this attribute MUST be null. The un-initialized value of this attribute MUST be 0.

The User Interface event types are listed below. Some of these events use the UIEvent interface if generated from a user interface, but the Event interface otherwise, as detailed in each event. A user agent MUST dispatch this event when the DOM implementation finishes loading the resource such as the document and any dependent resources such as images, style sheets, or scripts.

For legacy reasons, load events for resources inside the document e. See [HTML5] for more information. A user agent MUST dispatch this event when the DOM Implementation removes from the environment the resource such as the document or any dependent resources such as images, style sheets, scripts. The document MUST be unloaded after the dispatch of this event type. A user agent MUST dispatch this event when the loading of a resource has been aborted, such as by a user canceling the load while it is still in progress.

A user agent MUST dispatch this event when a resource failed to load, or has been loaded but cannot be interpreted according to its semantics, such as an invalid image, a script execution error, or non-well-formed XML. A user agent MUST dispatch this event when a user selects some text.

This event is dispatched after the selection has occurred. This specification does not provide contextual information to access the selected text. Where applicable, a host language SHOULD define rules for how a user MAY select content with consideration for international language conventions , at what point the select event is dispatched, and how a content author MAY access the user-selected content.

In order to access to user-selected content, content authors will use native capabilities of the host languages , such as the Document. The select event might not be available for all elements in all languages. For example, in [HTML5] , select events can be dispatched only on form input and textarea elements. Implementations can dispatch select events in any context deemed appropriate, including text selections outside of form controls, or image or markup selections such as in SVG.

The FocusEvent interface provides specific contextual information associated with Focus events. The focus events defined in this specification occur in a set order relative to one another. The following is the typical sequence of events when a focus is shifted between elements this order assumes that no element is initially focused :.

This specification does not define the behavior of focus events when interacting with methods such as focus or blur. See the relevant specifications where those methods are defined for such behavior. This event module includes event types for notification of changes in document focus. There are three distinct focus contexts that are relevant to this discussion:.

The operating system focus context which MAY be on one of many different applications currently running on the computer. One of these applications with focus can be a browser. When the browser has focus, the user can switch such as with the tab key the application focus context among the different browser user interface fields e.

One of these user interface fields can be the document being shown in a tab. When the document itself has focus, the document focus context can be set to any of the focusable elements in the document. The event types defined in this specification deal exclusively with document focus, and the event target identified in the event details MUST only be part of the document or documents in the window, never a part of the browser or operating system, even when switching from one focus context to another.

Normally, a document always has a focused element even if it is the document element itself and a persistent focus ring. For example, if a document has three focusable elements, with the second element focused, when a user changes operating system focus to another application and then back to the browser, the second element will still be focused within the document, and tabbing will change the focus to the third element.

A host language MAY define specific elements which might receive focus, the conditions under which an element MAY receive focus, the means by which focus MAY be changed, and the order in which the focus changes.

For example, in some cases an element might be given focus by moving a pointer over it, while other circumstances might require a mouse click. Some elements might not be focusable at all, and some might be focusable only by special means clicking on the element , but not by tabbing to it. Documents MAY contain multiple focus rings. Other specifications MAY define a more complex focus model than is described in this specification, including allowing multiple elements to have the current focus.

A user agent MUST dispatch this event when an event target loses focus. The focus MUST be taken from the element before the dispatch of this event type.

This event type is similar to focusout , but is dispatched after focus is shifted, and does not bubble. A user agent MUST dispatch this event when an event target receives focus. The focus MUST be given to the element before the dispatch of this event type.

This event type is similar to focusin , but is dispatched after focus is shifted, and does not bubble. A user agent MUST dispatch this event when an event target is about to receive focus. This event type MUST be dispatched before the element is given focus. The event target MUST be the element which is about to receive focus. This event type is similar to focus , but is dispatched before focus is shifted, and does bubble.

A user agent MUST dispatch this event when an event target is about to lose focus. This event type MUST be dispatched before the element loses focus. The event target MUST be the element which is about to lose focus. This event type is similar to blur , but is dispatched before focus is shifted, and does bubble.

The mouse event module originates from the [HTML] onclick , ondblclick , onmousedown , onmouseup , onmouseover , onmousemove , and onmouseout attributes.

This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. The MouseEvent interface provides specific contextual information associated with Mouse events. In the case of nested elements, mouse events are always targeted at the most deeply nested element. Ancestors of the targeted element can use event bubbling to obtain notifications of mouse events which occur within their descendent elements.

When initializing MouseEvent objects using initMouseEvent , implementations can use the client coordinates clientX and clientY for calculation of other coordinates such as target coordinates exposed by DOM Level 0 implementations or other proprietary attributes, e. The un-initialized value of this attribute MUST be false. The value of the button attribute MUST be as follows:. Some pointing devices provide or simulate more button states, and values higher than 2 or lower than 0 MAY be used to represent such buttons.

In these scenarios, take care not to interpret the value 0 as the left button, but rather as the un-initialized value. Some default actions related to events such as mousedown and mouseup depend on the specific mouse button in use. Though similarly named, the values for the buttons attribute and the button attribute are very different.

The value of the buttons attribute MUST be as follows:. Some pointing devices provide or simulate more buttons. To represent such buttons, the value MUST be doubled for each successive button in the binary series 8 , 16 , 32 , Because the sum of any set of button values is a unique number, a content author can use a bitwise operation to determine how many buttons are currently being pressed and which buttons they are, for an arbitrary number of mouse buttons on a device.

For example, the value 3 indicates that the left and right button are currently both pressed, while the value 5 indicates that the left and middle button are currently both pressed. Returns true if it is a modifier key and the modifier is activated, false otherwise. Numbers greater than 2 are also possible, but are not specified in this document.

The buttons attribute is a bit-field. If a mask value of 1 is true when applied to the value of the bit field, then the primary mouse button is down. If a mask value of 2 is true when applied to the value of the bit field, then the right mouse button is down. Implementations MUST maintain the current click count when generating mouse events. This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time.

The delay after which the count resets is specific to the environment configuration. The MouseEvent and KeyboardEvent interfaces share a set of keyboard modifier attributes and support a mechanism for retrieving additional modifier states. The following dictionary enables authors to initialize keyboard modifier attributes of the MouseEvent and KeyboardEvent interfaces, as well as the additional modifier states queried via getModifierState.

The steps for constructing events using this dictionary are defined in the event constructors section. Certain mouse events defined in this specification MUST occur in a set order relative to one another.

When a pointing device is moved into an element A , and then into a nested element B and then back out again, the following sequence of events MUST occur:.

Sometimes elements can be visually overlapped using CSS. In the following example, three elements labeled A, B, and C all have the same dimensions and absolute position on a web page. When the pointing device is moved from outside the element stack to the element labeled C and then moved out again, the following series of events MUST occur:. The following is the typical sequence of events when a button associated with a pointing device e.

The lag time, degree, distance, and number of mousemove events allowed between the mousedown and mouseup events while still firing a click or dblclick event will be implementation-, device-, and platform-specific. This tolerance can aid users that have physical disabilities like unsteady hands when these users interact with a pointing device.

Each implementation will determine the appropriate hysteresis tolerance, but in general SHOULD fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and SHOULD fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different.

If the event target e. If the target element is removed from the DOM as the result of a mousedown event, no events for that element will be dispatched for mouseup , click , or dblclick , nor any default activation events.

However, the mouseup event will still be dispatched on the element that is exposed to the mouse after the removal of the initial target element. Similarly, if the target element is removed from the DOM during the dispatch of a mouseup event, the click and subsequent events will not be dispatched. The Mouse event types are listed below. In the case of nested elements, mouse event types are always targeted at the most deeply nested element. Ancestors of the targeted element MAY use bubbling to obtain notification of mouse events which occur within its descendent elements.

The auxclick event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the non-primary pointer button, or otherwise activates the pointer in a manner that simulates such an action.

The actuation method of the mouse button depends upon the pointer device and the environment configuration, e. The auxclick event should only be fired for the non-primary pointer buttons i.

See click for a corresponding event that is associated with the primary button. The auxclick event MAY be preceded by the mousedown and mouseup events on the same element, disregarding changes between other node types e.

Depending upon the environment configuration, the auxclick event MAY be dispatched if one or more of the event types mouseover , mousemove , and mouseout occur between the press and release of the pointing device button. The default action of the auxclick event type varies based on the event target of the event and the value of the button or buttons attributes.

Typical default actions of the auxclick event type are as follows:. Receiving and handling auxclick for the middle button. In the case of right button, the auxclick event is dispatched after any contextmenu event. Note that some user agents swallow all input events while a context menu is being displayed, so auxclick may not be available to applications in such scenarios.

See this example for more clarification. Receiving and handling auxclick for the right button myDiv. The click event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the primary pointer button, or otherwise activates the pointer in a manner that simulates such an action. The click event should only be fired for the primary pointer button i. See auxclick for a corresponding event that is associated with the non-primary buttons.

The click event MAY be preceded by the mousedown and mouseup events on the same element, disregarding changes between other node types e. Depending upon the environment configuration, the click event MAY be dispatched if one or more of the event types mouseover , mousemove , and mouseout occur between the press and release of the pointing device button. The click event MAY also be followed by the dblclick event. Note that user-agent-generated mouse events are not dispatched on text nodes.

For maximum accessibility, content authors are encouraged to use the click event type when defining activation behavior for custom controls, rather than other pointing-device event types such as mousedown or mouseup , which are more device-specific. Though the click event type has its origins in pointer devices e. The default action of the click event type varies based on the event target of the event and the value of the button or buttons attributes.

Typical default actions of the click event type are as follows:. If the event target is focusable, the default action MUST be to give that element document focus. A user agent MUST dispatch this event before invoking a context menu.

When the contextmenu event is triggered by right mouse button, the contextmenu event MUST be dispatched after the mousedown event. Depending on the platform, the contextmenu event may be dispatched before or after the mouseup event. A user agent MUST dispatch this event when the primary button of a pointing device is clicked twice over an element. The definition of a double click depends on the environment configuration, except that the event target MUST be the same between mousedown , mouseup , and dblclick.

This event type MUST be dispatched after the event type click if a click and double click occur simultaneously, and after the event type mouseup otherwise. As with the click event, the dblclick event should only be fired for the primary pointer button. Canceling the click event does not affect the firing of a dblclick event. As with the click event type, the default action of the dblclick event type varies based on the event target of the event and the value of the button or buttons attributes.

Normally, the typical default actions of the dblclick event type match those of the click event type, with the following additional behavior:. If the event target is selectable, the default action MUST be to select part or all of the selectable content. Subsequent clicks MAY select additional selectable portions of that content.

A user agent MUST dispatch this event when a pointing device button is pressed over an element. Many implementations use the mousedown event to begin a variety of contextually dependent default actions. These default actions can be prevented if this event is canceled.

Additionally, some implementations provide a mouse-driven panning feature that is activated when the middle mouse button is pressed at the time the mousedown event is dispatched. A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements.

A user agent MUST also dispatch this event when the element or one of its descendants moves to be underneath the primary pointing device.

This event type is similar to mouseover , but differs in that it does not bubble, and MUST NOT be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements.

See also the mouseleave event type. A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element and all of its descendent elements. A user agent MUST also dispatch this event when the element or one of its descendants moves to be no longer underneath the primary pointing device. This event type is similar to mouseout , but differs in that does not bubble, and that it MUST NOT be dispatched until the pointing device has left the boundaries of the element and the boundaries of all of its children.

See also the mouseenter event type. A user agent MUST dispatch this event when a pointing device is moved while it is over an element. The frequency rate of events while the pointing device is moved is implementation-, device-, and platform-specific, but multiple consecutive mousemove events SHOULD be fired for sustained pointer-device movement, rather than a single event for each instance of mouse movement. Implementations are encouraged to determine the optimal frequency rate to balance responsiveness with performance.

In some implementation environments, such as a browser, mousemove events can continue to fire if the user began a drag operation e. This event was formerly specified to be non-cancelable in DOM Level 2 Events, but was changed to reflect existing interoperability between user agents. A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element or when the element is moved to be no longer underneath the primary pointing device.

This event type is similar to mouseleave , but differs in that does bubble, and that it MUST be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements. See also the mouseover event type. A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or when the element is moved to be underneath the primary pointing device. This event type is similar to mouseenter , but differs in that it bubbles, and that it MUST be dispatched when the pointer device moves onto the boundaries of an element whose ancestor element is the event target for the same event listener instance.

See also the mouseout event type. A user agent MUST dispatch this event when a pointing device button is released over an element. In some implementation environments, such as a browser, a mouseup event can be dispatched even if the pointing device has left the boundary of the user agent, e.

Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The coordinate system depends on the environment configuration. The deltaX, deltaY, and deltaZ attributes of WheelEvent objects indicate a measurement along their respective axes in units of pixels, lines, or pages. One movement of a common dented mouse wheel can produce a measurement of pixels is just an example value, actual values can depend on the current screen dimensions of the user-agent.

But a user can change their default environment settings to speed-up their mouse wheel, increasing this number. Because of this, authors can not assume a given rotation amount in one user agent will produce the same delta value in all user agents.

If a user agent scrolls as the default action of the wheel event then the sign of the delta SHOULD be given by a right-hand coordinate system where positive X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth away from the user of the document, respectively. Individual user agents can depending on their environment and hardware configuration interpret the same physical user interaction on the wheel differently. For example, a vertical swipe on the edge of a trackpad from top to bottom can be interpreted as a wheel action intended to either scroll the page down or to pan the page up i.

The WheelEvent interface provides specific contextual information associated with wheel events. The precise measurement is specific to device, operating system, and application configurations. A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device such as a mouse-ball, certain tablets or touchpads, etc. Depending on the platform and input device, diagonal wheel deltas MAY be delivered either as a single wheel event with multiple non-zero axes or as separate wheel events for each non-zero axis.

The typical default action of the wheel event type is to scroll or in some cases, zoom the document by the indicated amount. If this event is canceled, the implementation MUST NOT scroll or zoom the document or perform whatever other implementation-specific default action is associated with this event type.

In some user agents , or with some input devices, the speed that the wheel has been turned can affect the delta values, with a faster speed producing a higher delta value. Calling preventDefault on a wheel event can prevent or otherwise interrupt scrolling. For maximum scroll performance, a user agent may not wait for each wheel event associated with the scroll to be processed to see if it will be canceled. In such cases it is possible that only the first wheel event of a scrolling sequence is cancelable.

For the rest of the wheel events the user agent should set their cancelable property to false. Input events are sent as notifications whenever the DOM is being updated or about to be updated as a direct result of a user action e. For a list of valid values for this attribute, refer to the [Input-Events] specification. The un-initialized value of this attribute MUST be the empty string "". The input events defined in this specification MUST occur in a set order relative to one another.

The event also applies to elements with contenteditable enabled, and to any element when designMode is turned on. Keyboard events are device dependent, i. Tim Down's answer is so much superior than the accepted answer at the moment. JuanMendes - Googling "javascript event. Is that something you feel is "undesireable"?

Add a comment. Active Oldest Votes. Be aware that the code below should not be used for non-printable keys such as arrow keys, which you should instead detect in the keydown event: document. Improve this answer. Tim Down Tim Down k 69 69 gold badges silver badges bronze badges. Toskan: The accepted answer was posted a few hours before mine, and may have been accepted before I posted mine. OP let Tim down by not accepting this as answer! Deprecation notice as of September KeyboardEvent.

Sablefoste 3, 3 3 gold badges 35 35 silver badges 52 52 bronze badges. It does not really require Firebug, only some sort of console. Just another note of help for all who find this will post on other e.

I made a post at jQuery forums that list a good majority of e. Please look for the alternatives, such as KeyboardEvent. See more here. You should use KeyboardEvent. Anastasis Anastasis 1 1 gold badge 6 6 silver badges 23 23 bronze badges. Note that IE11 and Edge18 don't consistently implement the spec. During an event, e : e. Look at the code below: document. Let Me Tink About It Sayan J. Das Sayan J. Das 7 7 silver badges 16 16 bronze badges. Sign up or log in Sign up using Google.