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

Re: Marked addEventListenerNS and removeEventListenerNS At Risk

From: (wrong string) Ůski <1981km@gmail.com>
Date: Sat, 19 Sep 2009 15:09:28 +0200
Message-ID: <56943CB875EB4755837AEC4A7BE1B12F@kmPC>
To: <www-dom@w3.org>
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. If somebody (within W3C, another standards body, a vendor, whatever) specifies an interface inheriting from EventTarget and a couple of events to support and this interface may be implemented on objects also supporting events specified elsewhere (or to be specified in the future), the most natural thing to do is to put them in a namespace so that the local names are scoped in a separate controlled universe. The suggestions to use com.vendor.focus, org.w3c.FooSpec.ready and similar names would be equally (in)applicable to element types (<org.w3c.html.section>, <gov.pl.podatek.stawka>, anyone?). When good yet unused names become scarce, specs will start to define fewer events than optimal, with additional information allowing to choose the appropriate processing (e.g. with switch in ECMAScript). XMLHttpRequest does that already with readystatechange, although for a different reason (Microsoft's original implementation).

Initially we namespaced just element types and attributes. Soon it became clear that other kinds of identifiable things on the Web would benefit from this mechanism and it was extended to cover just about anything. I believe events shouldn't be denied this benefit if they are, as many signs indicate they could, gain much more universal importance in the platform than most people contemplated not long ago. And implementation doesn't really seem so difficult. It has already happened in existing software, so those implementors can be asked if they found it a major obstacle to deal with. Is it anything more burdensome than using a pair (namespaceURI, localName) for identification (that only involves being able to compare) rather than just a Name? If init...NS methods are too much, obsolete them (see my next post on difference between obsoleting and deprecating), providing one of the discussed generic mechanisms.

Best regards,

Received on Saturday, 19 September 2009 13:10:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC