[whatwg] URN or protocol attribute

[Brett Zamir]

Hi,

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,
Brett