The Event interface itself is described, as well as the interfaces for event registration on nodes in the DOM, event handlers and eventlisteners, and several longer examples that show how the various event interfaces relate to one another.
There is an excellent diagram that clearly explains the three phases of event flow through the DOM in the DOM Level 3 Events draft.
These and the various Event Handlers on HTML or XML elements are the main entry points for events in the DOM.
DOMevent names within the scope of the element on which it occurs.
All mutation events are in the http://www.w3.org/2001/xml-events namespace.
When a user-agent processes a mutation event received in a REX message, in addition to dispatching the event it must also modify the tree (either before or after the event, as specified depending on the event type) according to the event type.
Event flow is the process through which the an event originates from the DOM implementation and is passed into the Document Object Model.
If neither event capture or event bubbling are in use for that particular event, the event flow process will complete after all listeners have been triggered.
Although event capture is similar to the delegation based event model in which all interested parties register their listeners directly on the target about which they wish to receive notifications, it is different in two important respects.
event, the interesting information in the event object is the mouse pointer coordinates, which mouse buttons are depressed, whether modifier keys like "shift" are currently depressed, and so on.
Events can even be stopped from further propagation, which prevents later observers from detecting that the event happened.
The DOMEvents specification defines a number of core events, as well as an API method to stop the propagation of an event, and cancel the default action associated with it.
The click’s original target, the , gets to see the event first, and then passes it upwards to the
for further processing, which passes it on to the
, which finally passes it up to the document.
You may look at these events as they are passed down from the document to the the target (capture), or as they are passed up from the target to its enclosing elements (bubbling).
When the eventlistener function is invoked, you get an Event object that tells you the target for which the event was destined.
If this DOM has been compiled with mutation event support enabled, it will send mutation events when you change parts of the tree; otherwise you may create and send such events yourself, but they won't be generated by the DOM itself.
In DOM, children of entities and entity references are readonly, as are the objects associated with DocumentType objets.
These events may be delivered in any order, except that the event reporting removal from such an existing parent will always be delivered before the event reporting its re-insertion as a child of some other node.
The DOM Level 2 is made of a set of core interfaces to create and manipulate the structure and contents of a document and a set of optional modules.
The DOM WG wants to get feedback on these, and especially on the two options presented for XML namespaces, so that final decisions can be made for the DOM Level 2 specification." Public comments on the new WD specification may be sent to the editors via the public mailing list at www-dom@w3.org.
The DOM Level 3 Core specification, which is now in Last Call status, is the latest in a series of DOM specifications produced by the W3C.
W3C DOM Events(Site not responding. Last check: 2007-10-14)
The W3CDOMEvents module has not been implemented at all in Explorer, so browser differences are much sharper than in the other modules.
When mouseevents occur on text or inline elements and bubble up to the containing element, Mozilla 1.2 and before and Safari v60 and v80 see the text node as the target of the event.
flag at the end states whether the event handler should be executed in the capturing or in the bubbling phase.
The technique described is based on server side DOMevents as currently proposed in the the WHATWG Web Applications 1.0 specification.
With server side DOMevents, the server would be returing events which get raised by the browser and can be handled just like regular DOMevents.
The current draft of Web Applications 1.0 does include an event class field that could be set on each event, and this field can be mapped to browser side event interfaces including UI related and input events (such as keyboardevents).
Peter Paul Koch has written a good and comprehensive introduction to events in HTML/XML documents and a comparison of the DOM and Microsoft event registration model.
I want to focus here on an issue with a single crossbrowser event, which is multiply registered on the same object.
The DOMEvents Level 3 specification indeed defines a method hasEventListenerNS exactly for that purpose.
The interfaces in these classes establish a generic system that allows eventlisteners to be attached to nodes.
Events nodes can respond to user interface events like mouseclicks, structure modification events like document edits, and anything else the implementation wants to support.
In practice, events are more relevant to JavaScript and other browser-based script systems than most XML programs; but they can be useful when an XML document is displayed in a browser or otherwise shown to a user.
DOM provides a structure that facilitates access to the elements of an HTML or XML document by scripting languages with object oriented features (e.g., JavaScript).
Hence, DOM is best used for applications where the document elements have to be accessed and manipulated in an unpredictable sequence and repeatedly.
The sequential SAX model is advantageous in such a case in terms of speed and memory consumption.
This specification defines the Document Object Model Level 2 Events, a platform- and language-neutral interface that gives to programs and scripts a generic event system.
This section describes the status of this document at the time of its publication.
The authors of this document are the DOM Working Group members.
On that note, you can send your thanks to Andrew Dupont considering he has worked very hard on the docs.
I think “hate” is too strong a word, but one of the DOM’s (necessary) drawbacks is that its methods and properties are annoyingly verbose.
I say “necessary” because verbosity was by design — the DOM is intended to be a language-independent API, so it can’t rely on shortcuts specific to JavaScript.
