- From: Stewart Brodie <stewart.brodie@antplc.com>
- Date: Thu, 24 Apr 2008 11:59:33 +0100
- To: public-webapi@w3.org
Web APIs Issue Tracker <dean+cgi@w3.org> wrote: > ISSUE-123: Should DOM Level 3 Events support namespaced events? > > http://www.w3.org/2005/06/tracker/webapi/issues/123 > > Raised by: Anne van Kesteren > On product: DOM 3 Events > > There are several reasons for dropping namespaced events as we discussed > during today's telcon: > > * Browser vendors have not implemented them Large desktop browser vendors have not implemented them. I implemented them in our browser - it was a trivial job. > * There has been very little to no demand from Web developers for these > features. Out of interest, how has demand, or lack of it, been established? Is it from postings to this mailing list or via some other mechanism? > * Implementing this feature increases QA cost That is true for any change, whether it be a feature or bug fix, though. > * Implementing this feature increases the complexity of the Web platform In other standards, the need to namespace has been ignored initially and had to be hacked on later. XML has done it like this, CSS has done it like this (well, it is trying to, but it is struggling to maintain backward-compatible semantics). I do not believe that namespaced events introduce much complexity to the web platform at all, provided that they are added now. It is vital that if the APIs under consideration for enumerating event listeners ever come to pass (and I think that's a bad idea for several reasons), that namespaces are put in Events first, because trying to retrofit namespaces after that will definitely add a great deal of complexity and QA cost. Introducing vast amounts of complexity has not stopped the development of other features (HTML5, for example), so given the minimal impact that this feature has, I don't see "adding to the complexity of the web platform" as an issue here. > The main argument in favor seems to be libraries being able to distinguish > event types from each other. Given that they currently use a simple string > for this purpose (dojo.xxx, etc.) and that seems to work fine having > namespaces does not seem necessary here. You probably ought to insist on a full domain name - in which case, you might as well use namespaces anyway, as that's what they're for. If you choose to drop this feature, then you must also add a statement to the effect that any new events that appear in W3C standards will have "org.w3c." on the front of the name to avoid collisions with other content. > There's also not infinite libraries and you won't use infinite libraries > on a Web page so the advantage seems really slim. Infinite libraries is not the real issue. It's two libraries trying to use events with the same name collision that's the problem, especially when unknown third party content is injected into other content (e.g. advertising content is often under the control of a third party). It is not acceptable to then demand that one (or both) of the parties alter their content - they will say that it works for them and they don't want to incur a huge QA cost either. -- Stewart Brodie Software Engineer ANT Software Limited
Received on Thursday, 24 April 2008 11:00:10 UTC