Re: ISSUE-123: Should DOM Level 3 Events support namespaced events?

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