Internet Explorer has an attribute on anchor elements for URNs: http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx

This has not caught on in other browsers, though I believe it could be a very powerful feature once the feature was supported with a UI that handled URNs (as with adding support for custom protocols).

Imagine, for example, to take a link like:

<a href="http://www.amazon.com/...(shortened)...." urn="isbn:9210020251">United Nations charter</a>

The default behavior would simply follow the link, but if a user agent supported the @urn attribute, and if the browser (or browser add-ons) had registered support for that URN namespace identifier (here "isbn"), it could, for example, open a dialog to ask which handler to use (or whether to always use it), it could ask or otherwise allow in preferences an HTML page (with wildcards) where the attribute's content could be passed, or it could give the option whenever the user right-clicked to choose which handler they wanted to use for a given link.

Likewise, a link like:

<a href="http://en.wikipedia.org/wiki/United_Nations_Charter"; urn="wikipedia:United_Nations_Charter">United Nations charter</a>

...could alternatively be opened in the corresponding Encyclopedia Britannica (or Amazon, etc.) page (assuming "wikipedia" could be accepted as a URN namespace, thus unburdening the IANA from coming to consensus on the web community's many and ever-expanding names). Users would be free to follow the content in the data viewer they wished to use, while sites would be free to avoid committing too strongly to any particular handler implementation (i.e., the website they specify is only a default).

Although software has been made to handle URNs within @href (see, for example, https://addons.mozilla.org/en-US/firefox/addon/1940 ), it is really a lot to ask for website creators to support a protocol without being certain of support (or at least a JavaScript fall-back which could test for support). With this proposal, there is no real down-side to content creators, users, etc. (nor, given the simplicity of this proposal, even really, it would seem to me, to specification editors!), to adding an extra attribute (which need have no precise behavior associated with it).

Actually, maybe even a "protocol" attribute would be in order to give a similar alternative between a default website and a generic protocol handler (and maybe the "urn:" protocol could be subsumed into this even more general attribute).

So, my suggestion is to add to <a/> a @urn or, even better, a @protocol attribute (since the latter is more comprehensive and also already has a formal API for JavaScript registration of handlers). If some browsers are not keen on supporting it, maybe there could be a simple test to check for support, since it is not strictly necessary, but could unobtrusively offer more choice to users.

best wishes,

Reply via email to