XSeen uses DOM-style events. This allows easy cross over from regular HTML to XSeen and back as well as dealling with events solely within XSeen.

Some events are indicated just by their action (e.g., click, mouseenter). In XSeen these events deliver a TRUE value to their target when the specified event happens.

Other events are issued continuously while the event happens (e.g., mouseover). These events have other data associated with them (frequently position). It is the responsibility of the event handler to correctly deal with the event contents. It is the relation between the event type and the target field that determines what needs to be done.

For example a trigger event (e.g., mouseenter) can easily be sent to a field that controls a simple (true/false) behavior. In this case, the act of generating the event is sufficient information to determine what happens. If XSeen needs to track mouse motion in/over an object and changing coordinates are fed to a field, then the event handler needs to access the event object and inspect the position coordinates. It may be necessary to perform a coordinate transformation on those coordinates to correctly go from 2D to 3D or vice-versa.

Event routing starts with identifying the emitter of the event (by element ID) [note: it may be possible to handle multiple elements through a class value], and the event type (any one of the allowed HTML/DOM or XSeen events). The terminal of the event route is the target element (specified by element ID) and field for XSeen nodes. For HTML elements, it is necessary to specify a JavaScript function. That function is the developers responsibility.

This table summarizes the requirements and steps for execution. Note that HTML events may be generated by XSeen elements (e.g., click). These are treated as 'From HTML Element' events.

It is necessary to provide some feature so that developers can customize event handling. This needs the capability to calling a developer-provided hook in the event processing chain.

All notifications from one node to another happen by events. Multiple nodes can listen for an event ("fan-out" in X3D terminology) and multiple events can be directed to a node ("fan-in"). There is no traditional X3D event cascade. Animation does not happen through events, but separately scheduled animation loops that are dependent on getting an animation frame (using WebGL terminology). Events are primarily meant as control and reporting features; however, there are use cases to track mouseover events to "draw" on an image or object (image texture). Events are "TRUE" states, as in the mouse has entered this area, or the button was clicked; not "FALSE" states when the mouse has not entered this area, or the button was not clicked. For conditions that have true and false states (e.g., mouse over this object), there is an event for TRUE (mouseentered) and one for FALSE (mouseexited). It is important to node that in both conditions a TRUE event is generated.

The traditional X3D means for handling events is very appealing because it establishes a visual programming link from event generator to event consumer. For single events that go to XSeen nodes, it is a fairly simple matter to use the X3D ROUTE statement where the the source and destination nodes are identified by their ID attribute value. The source field is the event type that is appropriate for an the source node. The destination field is the receiving field for the event. It will be "sent" a TRUE event when the source event is activated. A FALSE event is never sent. It might be possible to identify the source and/or destination nodes by class name. In that case XSeen would need to build a list of matching nodes and add an event handler for each source node. If there were multiple receving nodes, that should be determined at run-time.

I'm not sure how to handle the case of Continuous events. There needs to be some sort of data handling/filtering or perhaps the destination is pre-built to handle specific events.