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 23:33:34 +0200
Message-ID: <11537EEC994D44989858DF0538015404@kmPC>
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: <www-dom@w3.org>
Hi, Jonas!

> 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", ...);
I read this argument before, squeezed between some others in a row. Somehow I didn't attribute much weight to it. Thanks to our getting into this level of detailed discussion now I clearly know why. So it's a good thing :-).
Let me share with you.

You could do var myNs = "http://example.com/myNamespace" and use the myNs variable instead of the namespace name therefrom. This would be the programming equivalent of defining the myNs prefix in markup.

But you've also given me the idea of going further. Creating this variable would be a constant overhead (compared to linear had the namespace name indeed to be fully written at each occurrence) but still about twice as much as ideally needed (and duplication also harms maintainability and other stuff) given the prefix declaration very likely present already in the markup (probably there is markup in most cases you'll want to use this API). So you can call Node.lookupNamespaceURI. You could shorten it using a universal utility function (e.g. function f(node) {return function(prefix) {return node.lookupNamespaceURI(prefix)}}, used thus: f(node)(prefix)). Maybe something like this could make it into an upcoming version of DOM Core. How about Node.ns[prefix]?

Best regards,

Received on Saturday, 19 September 2009 21:34:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC