XML Events Comments

The requirement behind having a distinct "target" attribute (corresponding to Event.target) and to introduce the concept of "observer" isn't obvious and would appear to result in coding errors when
people use "target" to mean what you called observer.  The case of wanting to listen on an ancestor node but only respond to events on one particular child would seem to be both rare and to be
adequately handled by a simple if statement in the handler.  Unless there is a compelling reason, I'd eliminate the current target semantics and use the "target" attribute to represent the EventTarget
on which the listener is registered.

----------


Section 3: Naming Event Types

The use of namespace qualified events types has no precedent in the DOM Level 2 or 3 Events module.  There is no mechanism to register an handler that takes both a namespaceURI and local name.  If the
namespace URI and local name are combined, the name no longer adheres to the XML Name production as required for the type argument to EventTarget.addEventListener().  If the the prefix is just a
decoration and not resolved to a corresponding xmlns attribute, then the event type is not really a qualified name.

SVG events should be discussed in this section at least comparable to the treatment of HTML events.

The enumeration of camel case equivalents of established DOM Events methods (subtreeModified for DOMSubtreeModified) and the instruction that camel case names should be used in preference to the
existing names is problematic.  Does this prohibit using the names as defined in the DOM Events specs?  If the camel case names are strictly a convenience and the existing DOM Events spec names can
also be used, then it is tolerable.  However, introducing a distinct set of aliases for established event types seems undesirable.

---------------

The DOM Level 2 Event Recommendation is not listed in the references.

---------------

Attribute names

The use of the attribute name "phase" (which corresponds to the useCapture parameter from the addEventListener call and not Event.phase) in close proximity to propagate and defaultAction (which
correspond to calling Event.stopPropagation and Event.preventDefault) might confuse users who think it implies a conditional on Event.phase like target evaluates a conditional on Event.target.

The confusion between XML Events and DOM Level 2 Events could be minimized if the attributes more directly corresponded to the names in DOM Level 2 Events.  Specifically, phase changed to useCapture,
propagate to stopPropagation and defaultAction to preventDefault, all as boolean attributes with a default of false.

--------------

The handler attribute identifies a URI which (apparently) can be dereferenced to obtain an object that supports the EventListener interface.  As such, it seems very minimal compared to the <object>
element used to represent other downloadable behaviors.  For example, it is not possible to specify a mime type to specific a specific implementation of the behavior, initialization parameters, or a
distinct data source to initialize state.

Could the existing <object> semantics in XHTML be leveraged to provide a richer mechanism to instantiate the listener?  The handler attribute could be changed from an URI to an IDREF that should
resolve to an <object> element and if an <object> element is nested in an <listener> element and no handler is specified then the embedded object is registered.

---------------

An XML Schema would seem to be desirable, especially if this is to be used by XML technologies other than XHTML.

Received on Thursday, 1 November 2001 16:55:46 UTC