Re: null namespace in DOM L3 Events inconsistent with other specs

On Wed, 2002-08-14 at 23:23, Curt Arnold wrote:
> From section 1.1
>  
> For backward compatibility reasons, the dispatching of an event will
> ignore namespace URIs if either the event or the event listener has a
> null namespace URI.  If a DOM Level 2 event (i.e. with a null
> namespace URI) is dispatched in the DOM tree, all event listener that
> match the type will be triggered as described in Description of event
> flow. If a DOM Level 3 event (i.e. with a namespace URI) is dispatched
> in the DOM tree, all event listener with the same type and the same or
> null namespace URI, will be triggered as described in Description of
> event flow.
>  
> -------------------
>  
> This basically results in a null namespace parameter to
> addEventListernerNS acting like "*" in getElementsByTagNameNS.  It
> also has the effect of discouraging use of  common event names (like
> "load") in arbitrary namespaces since existing DOM L2 Event clients
> would receive those messages in addition to the intended
> {http://www.w3.org/2001/xml-events}load and {null}load events.
>  
> The motivating factor is to not break existing event handling code
> while effectively changing the DOM defined events from not being in a
> namespace to being in {http://www.w3.org/2001/xml-events}.  Instead of
> having addEventListenerNS(null, "load") or
> addEventListener("load") receive any event named "load", it would not
> be difficult to define the behavior so that it would only get
> {http://www.w3.org/2001/xml-events}load and {null}load events.
>  
> One mechanism to accomplish this would be to add an additional boolean
> parameter or the init*EventNS's that mark the event as being
> dispatched in a compatibility mode.  If this parameter was set on the
> event, then the event should be dispatched to any listener that
> matches its namespace and event type or any listener registered with
> addEventListener() or addEventListenerNS(null,) and its event type.
>  
> The second option would be to imply that behavior for any event in
> {http://www.w3.org/2001/xml-events}.

I thought I replied to this issue a long time ago but I cannot find a
trace of the announcement, so here is one again:
The motivation behind ignoring namespaces, if either the event or the
event listener has a null namespace URI, was indeed to not break
existing code. It is not obvious that having an other parameter on
init*EventNS for the backward compatibility mode would be a better
approach to the problem. The second option doesn't seem appropriate
either since it only addresses event types by the DOM specifications
(since we are the only ones to use the xml-events namespace for the
moment; XML Events will probably reuse latter but other specifications
shouldn't, like SVG). Specifications that using namespace for event type
should not be discourage to use common event names, but encourage (or
better require) the use of a DOM Level 3 implementation on top of it. 
So, after discussion, the final call was to leave the specification as
it is, so let us know if you think we need further discussion. We also
rejected the following issue regarding createEvent: the namespace is
part of the event type and therefore needs to stay associated with the
typeArg parameter of initEvent*NS.

Philippe
PS: We closed the following issues:
http://www.w3.org/2002/07/DOM-Level-3-Events-issues/issues.html#arnold1
http://www.w3.org/2002/07/DOM-Level-3-Events-issues/issues.html#arnold2

Received on Friday, 20 June 2003 17:45:40 UTC