W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Marked addEventListenerNS and removeEventListenerNS At Risk

From: Doug Schepers <schepers@w3.org>
Date: Sat, 19 Sep 2009 17:14:31 -0400
Message-ID: <4AB549B7.6090408@w3.org>
To: www-dom@w3.org
Hi, Folks-

Jonas Sicking wrote (on 9/19/09 4:28 PM):
> 2009/9/19 Krzysztof MaczyƄski<1981km@gmail.com>:
>>  I'm strongly against removing namespace support from DOM Events. The use case
>>for them is as valid as that for element types - to avoid clashes.
>
> There is an important difference.
>
> Elements and attributes use namespaces, but use a prefix mapping
> mechanism so that you won't have to type the full namespace every
> time. Events don't have that.
>
> With Events you'd always be writing:
>
> someEventFunction(..., "http://example.com/myNamespace", "myEvent", ...);
>
> With the proposed changed you'd instead write:
>
> someEventFunction(..., "http://example.com/myNamespace/myEvent", ...);
>
> where 'someEventFunction' is initEvent, addEventListener,
> removeEventListener etc.
>
> So on the whole not that big of a difference.

In addition to this, there is another important distinction.  With 
namespaces in markup, implementations must all (at a minimum) parse the 
markup into the DOM, in the correct namespace; whether the UA does 
anything with that content beyond that depends on the namespaced 
language, the host language, and the native capabilities of the UA.  It 
may be rendered, or it may simply provide metadata.  Authors can still 
access and manipulate it, regardless of UA support.  For example, if I 
have some XHTML, I can put SVG, MathML, and RDF content in it, each in 
its own namespace; if an browser doesn't support SVG, the SVG markup 
(and its metadata) is still there... <svg:title> and <svg:desc> can be 
rendered as text; if it doesn't support MathML, the equations are still 
there, and could be styled somewhat using CSS; and the RDF is there for 
any metadata extractor (as with some FF extensions).  So, namespaced 
markup is still useful even if the implementation doesn't support the 
namespaced language (but does support namespaces in general).

With events, however, if the implementation doesn't support the event, 
it does nothing else with it, and authors can't do anything more with it.

Also, namespaced markup is more typically a large set of related 
elements and attributes.  Events don't tend to be as tightly coupled 
with one another (at least on the same scale), and this smaller set of 
names allows for easier clash-proofing via naming conventions.  For 
example, there might be a set of related events, 'dragstart', 
'dragmove', and 'dragdrop', let's say... they could be done as 
namespaces ('drag:start', 'drag:move', and 'drag:drop'), but it's just 
as easy to keep that association with the event names, and is arguably 
easier and more descriptive.  Clashes can be avoided simply with a 
prefix convention: 'ds_dragstart', 'ds_dragmove', and 'ds_dragdrop'.

So, while I'm sympathetic to the extensibility use case, I am not 
convinced that namespaced events are as useful or as critical as 
namespaced markup, and namespaced events do add considerably to the 
implementation burden.  The most compelling argument I could see is if 
other specs or content critically depends on keeping them, and thus far, 
I have not seen strong evidence for that (though I am still looking).

That said, if we do introduce a generic event initializer with writable 
attributes prior to dispatch (as has been discussed), the namespaceURI 
could simply be another optional attribute, which should be relatively 
minor for implementers to support (though it would require keeping the 
NS-aware event listeners), and no burden to authors.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Saturday, 19 September 2009 21:14:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT