- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 19 Sep 2009 17:14:31 -0400
- 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 UTC